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Abstract 

Although recent advances in graphics workstations promise much computing power for the future needs of 
rcscarchors, traditional approaches to software organization waste much of tliis power. Most systems treat the 
workstation tis either a fixed- function terminal or a self-contained personal computer; these roles have 
limitations that can be overcome by considering the workstation a multi-function component of a distributed 
system. Traditional standard graphics packages and object-oriented window systems offer important 
functionality, but a third approach, virtual terminal management systems, is more appropriate for a 
distributed operating system. - 

The Star. ford Distributed Systems Group has implemented such a distributed system for graphics 
workstations, organized as a collection of servers providing services to clients. Major issues are how to 
partition functions between the server and its clients, and physically partition the server. In particular, tlic 
service Uiat displays graphical objects is called the Virtual Graphics Terminal Service (VGTS). The VGTS 
architecture is described, as well as a prototype implementation. 

This thesis discusses the trade-offs involved in partitioning of function in a distributed graphics system. 
Performance is one important property traded for advanced functionality or decreased cost. To provide 
adequate performance in a distributed system, communication costs should be kept low, as well as the 
frequency of the communication. By providing modeling as well as viewing facilities, the VGTS reduces tlic 
communication required between applications and the service. 

Measurements verify that performance is insensitive to network bandwidth, but depends lieavily on CPU 
speed and protocol characteristics. Using structme provides important speed improvements in some cases, 
but other basic factoid such as inner loop optimization and proper batching of requests make even latter 
differences. 

Finally, conclusions are drawn regarding the partitioning approaches taken in the VGTS. The VGTS is 
suitable for a large class of applications that perfonn graphics as an aid to user interface, and is portable to a 
wide range of powerful workstations. Moreover, the VGTS can be used as a basis for further research on 
many open questions in distiibuted systems. 
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Introduction 

When computers were first invented, their time was so valuable that elaborate batch systems were devised. 
People would spend hours preparing commands and data to be read, processed, and printed out by the 
computer. In the 1960s the concept of timesharing was introduced, dedicating inexpensive terminals to each 
user, many of whom shared a computer. The first timesharing systems were modeled after batch systems, but 
soon the advantages of interactive programming became worth the extra cost Throughout the 1970s many 
computer systems were designed specifically for timesharing. 

Recent advances in VI,.S1 technology make powerful yet physically small and inexpensive computer systems 
feasible. Related advances in network technology have made computer systems that communicate to other 
systems the rule rather than the exception. One of the ideas behind timesharing can be applied with today's 
different cost constraints: replicate inexpensive components and share the expensive components. 

1.1 Graphics Workstations 

The computing resource dedicated to each single user is called the workstation. Tn timesharing systems the 
workstation is just a fixed fiinction terminal, but tlie falling cost of microprocessors results in a shift to more 
powerful workstations. For the rest of the discussion we will assume that the workstation contains some kind 
of programmable processor, some memory, at least one display device, and at least one input device. 
Workstations are often connected in clusters, forming a workstation-based distributed system, as illustrated in 
figure 1-1. 

The advent of high-performance graphics workstations has been a mixed blessing. Inexpensive 
microprO':essors seem to promise unlimited computing power to satisfy everyone's needs. However, now that 
the information being processed and viewed is becoming more valuable than the hardware doing the 
processing, old techniques for organizing computing systems are no longer valid. In particular, common 
activities like information display often have processors dedicated to them, but still require access to other 
computing resources. 

Although they are interconnected, most workstation systems built to date continue to treat the workstation 
solely as a fixed-function terminal or a self-contained personal computer. More interesting roles exist 
between these two extremes, especially considering the next logical step in the organization of compudng 
systems: many computing elements per user cooperating on the same task. To accomplish this cooperation, 
the tasks must be partitioned or divided at appropriate points depending on many factors. This thesis 
attempts to investigate and characterize some experimental attempts at partitioning in a distributed graphics 
system. The goal is not a system that solves all the problems of distributed graphics, but rather to design and 
build a prototype that can be used to evaluate one approach. 

1 .2 Role of tlie Workstation 

It is fairly certain that both computing power and communication capability will become more pervasive in 
the future, and these trends will continue for some time. At present, however, tlic bottleneck in the 
development of network -based systems has become the software, with much of tlie potential of powerful 
workstiition hardware being unrealized. The first key problem is to find the appropriate role for the 
workstation within the context of the whole system. There arc three basic approaches to the role of graphics 
workstations in a computing environment: as a terminal, as a personal computer, and as a component of a 
distributed system. 
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1 .2.1 The Workstation as Terminal 

When a low performance workstation is used with a timesharing system, it is convenient to treat the 
workstijtion as a terminal [91]. This concept applies not only to traditional alphanumeric terminals, but also to 
biunap (called "all points addressable" by IIJM) displays. Bitmap displays contain an area of memory which 
stores every pixel of the displayed image. The advantages of using graphics terminals with timesharing 
systems has been recognized for many years, but the cost of the necessary display hardware, compute power, 
and communications bandwidth has been prohibitive until recently [70]. 

One of the first graphics workstations with local network capability was the Alto, designed and built by the 
Xerox Palo Alto Research Center (FARC) [142]. The ADiS System [127], the Alto Terminal Program [12], 
and Deutsch's Remote BitBlt protocol [47] were developed to allow programs on a timesharing system to use 
an Alto as a display device across a network. However, in each of these protocols all but the lowest level 
viewing operations were done on one particular host, with the workstiition only manipulating bitmaps. 'Hiis 
was due to the limited speed and main memory capacity of the AItu, designed in die early 1970s. Since 
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current workstations have faster processors and larger memories, new architectures should take advantage of 
this increased power. 

Bell Lab's Layers System [105] for the Blit terminal [72], now called the Teletype 5620, provides a similar 
bit-map interface to tlie application. An application can run on the terminal and communicate to a (single) 
host using a higher-level protocol. Unfortunately, these protocols are not standardized, and the Layers system 
is only designed for one particular kind of workstation to communicate with one kind of operating system. 
Since many users are only concerned with one operating system or one terminal, tliese systems may be 
succcssfiil. In fact, the ability to act as a terminal is an important capability that should be included in any 
workstation-based system. However, even tlie designers of the Layers system are working on a more flexible 
approach that does not waste die power of more advanced workstations. 

1.2.2 The VVorkstation as Personal Computer 

For higher performance workstations, one popular approach is to construct a small model of a larger 
timesharing system. This is a simple and powerful idea pioneered by the Alto computer at Xerox PARC, and 
now adopted in many new products. Examples include tlie various Lisp Machines [16], the Pcrq [144], and 
many other new commercial systems being announced weekly at the time of this writing. 

One principle motivation behind the personal computer approach is to avoid the partitioning problem, and 
instead offer a single "integrated" system. But in reality each personal computer is isolated, resulting in a 
highly partitioned system widi the following practical problems: 

• Cost: There are economies of scale involved in devices such as disks. For example, 30 10 Mbyte 
disks cost much more than a single 300 Mbyte disk. A moderately sized disk would essentially 
double the current cost of Uie workstation. Typically configured Lisp Machines sell for $100,000 
to $200,000. Since many organizations do not have $1000 terminals for each member, tliey 
certainly will not spend 200 times that amount for a single user. 

• Reliability: An office environment is not as controlled as a clean, air-conditioned machine room. 
Preventive maintenance and repair of delicate mechanical equipment is much easier for 
centralized facilities. 

• Flexibility: The personal computer model provides for rigid control on tlie number of users; if 
you are not one of the few who own one, or find one to share, you can not use any computing 
resources du ri ng peak hoars. 

• Performance: There arc two aspects of performance. Although fast response to user interaction 
(such as editing [57]) favors personal computing, high-throughput and low-interaction activities 
(such as compilation) favor large shared processors. 

• Comfort: Adequately sized disks arc large and noisy, producing an unwelcome intrusion into the 
ofiicc environment, with associated power requirements and heat dissipation problems. For 
example, the Xerox 1100 Lisp workstations at Stanford are physically centralized, with only Uie 
displays and keyboards outside the machine room. 

• Duplication: Many of the files on each disk arc duplicated. This obviously wastes space, but 
more importantly, it causes problems with propagation of updates and useless duplication of 
software maintenance effort. 

There will still be many commercially successful personal computer products. For example, the entire 
Unix [111] operating system has been ported to a workstiUion with a local disk interface for each 
workstation [68, 118], Reasons for this success include the value many people put on total control, and the 
"personal" nature of much computing [116]. For instance, a small business would probably initially prefer 
one self-contained personal computer. 



6 



PARTITIONING OF FUNCTION IN A DISTRIBUTED GRAPHICS SYSTEM 



However, if tliat business outgrows the single personal computer, and wishes to share large distributed 
databases, the problems described here will eventually arise. Except for the low-performance computers 
purchased for home use, most so-called "personal" computers used for science and busness are actually 
purchased by some group or department, and are therefore actually shared. Furthermore, the high cost of 
these scientific workstations has limited shipments to only a few thousand units [153]. For larger, multi- 
person projects that arc performed in research and development environments,- small self-contained systems 
are not always desirable. 

Even if workstations arc available, current researchers still heavily use centralized server hosts. The 
following are some reasons it might not be possible or desirable to run all applications on the workstation: 

• The application may require fast floating point hardware. 

• The application may require large virtual or physical memory. 

• The application may require frequent access to a large database. 

• The application may be written in a particular language or dialect. 

• The application may require a license to run on each different CPU. 

• The application may access secure information that should not be transmitted over a network. 

• The application may perform I/O directiy to a particular device. 

• The application may contain dependencies on a particular machine or operating system. 

Even if the necessary resources are available as an option for the workstations, they are often too expensive for 
widespread use. 

One could argue that since hardware costs are decreasing, the personal computer model will inevitably 
dominate in tlic end. But the decrease in hardware costs means that software costs become relatively more 
important [15(')|. It is well known that tlic largest portion of software life-cycle costs goes to maintenance [18]. 
Therefore, ease of software maintenance should be an important issue in evaluating a computing system 
architecture. With individual personal computere, all users have to do their own software maintenance. This 
results in a potentially enormous increase in the costs assix;iated with distiibuting and installing new versions 
of software. 

Even considering only hardware costs, self-contained personal computers may eventually become more 
expensive than other alternatives. One might reason that since memory costs are decreasing, and memories 
are getting more dense, the trend will be to computer systems with higher ratios of memory to processing 
power. However, a typical computer ten years ago was an IBM Systcm/370 with about a million bytes of 
physical memory [104]. Today, a representative computer is the IBM PC, with almost half the processing 
speed, but only one tenth as much memory, typically about lOOK bytes [54]. Of course the lower price of Uic 
PC means thai many more people can alTord one. On the other hand, the organization that ten yeare ago had 
a 370/138, can now afford a machine with a prix:essor about eight times faster and sixteen times as much 
memory. Large computers are expanding principally by adding memory, while smaller computers are getting 
less expensive principally by keeping memory small. 

More interesting evidence is the relative price of memories and processors. Today an MC68000 processor 
costs about $50, and a 64K bit memory chip costs about $5. 'llius, if a system has more tlian about ten 
memory chips per processor chip, the memory cost will dominate. Since the cost to produce integrated 
circuits in large quantities depends mostiy on packaging considerations such as the number of pins, tlie ratio 
of prcKCSsor to memory cost will probably stay fairly low. This provides motivation to design computer 
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systems that take advantage of low-cost processors by replicating them for each user, but share expensive 
resources such as memory. 

1 .2.3 The Workstation as a Component of a Distributed System 

Since most researchers who use personal computers quickly recognize the problems caused by isolation, 
manufacturers usually provide some form of communication capability. For example, a file transfer program 
may be used to transfer files eitlicr explicitly or semi-automatically between the personal disks. Other 
approaches use a remote disk or logical file system to intercept operations at tlic appropriate level, and route 
them instead to a remote disk or file access user module. There arc many practical reasons to eliminate 
expensive components such as secondary storage from each workstation. A diskless workstation is 
inexpensive, small, quiet, and has almost no moving parts to break. 

Several efforts, such as Locus at UCLA, modified standard operating systems to allow shared and replicated 
file systems [ISO]. Berkeley 4.2 Unix was intended for diskless operation, altliough for performance reasons 
most 4.2 systems still have local disks, and ail programs still run on tlie workstation [68]. Some attempts 
extend timesharing systems to handle remote execution [53], but a more comprehensive solution is needed. 
The file service abstraction, developed in projects such as Woodstock [137], can be generalized into the server 
model, resulting in more flexibility of interconnection. 

1.2.3.1 The Server Model 

The architecture to be presented in Chapter 3 treats the workstation as a multi-ftmction component of a 
distributed system. We do not waste its power by treating it solely as a terminal, nor do we isolate it from the 
rest of the world, under the false assumption tliat it can be all things to all users. Rather, by supporting a 
distributed operating system the workstation may perform any function best suited to the user, the hardware, 
and die applications at hand [79, 86, 109, 155]). 

In this view, tlie operating system is just a collection of servere, and a way of accessing those servers. An 
implementation of this model usually consists of cooperating kernels providing an inter-process 
communication system, and services implemented as processes^. The kernel of a server-based operating 
system acts analogously to a hardware bus, being essentially a communications switch. In addition to the 
physical wires used to connect modules in a hardware bus, a stimdard protocol is agreed upon to define the 
semantics of the communication. Similarly, in our software model, in addition to the ability to send message, 
a protocol is defined for tlie meaning of the messages. 

This model docs not make the system versus user distinction; die design is in terms of "clients" which 
invoke the services of a particular server. For example, the concepts of "terminal" and "personal computer" 
are now merely roles played by some collection of processes and processors at any given time. 'I'he result is 
much more flexibility in the partitioning of tlie resulting system. 

1.2.3.2 Networl<Transparency 

Uy considering the workstation as a component of a distributed system, we could consider a single 
underlying communication concept for "network transparency." In general, network transparency is a 
worthwhile goal: programs should be as independent as possible of the location of dicir execution and the 
resources they use. However, every system has a boundary on diis transparency, so tlie problem of 
communicating to tlie outside diis boundary must be addressed eventually. In fact, all the computing 



In fact, in many ways the kernel itself can be viewed as a server, providing objects such as processes and messages. 
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resources in the world can be considered a single computer system, with many disconnected components. 
This motivates communication between various kernels which may have vastly different underlying 
communication concepts, resulting in what might be called a distributed kernel. Network communication 
always has some cost associated with it, so perfect transparency is never possible with respect to performance. 
Chapter 3 describes a system which has been developed to help address some of these issues. 

1 .3 Kinds of Partitions 

The hardware trends discussed in the previous sections result in a physically distributed computing system, 
with a corresponding partition required of the software. There are several forms that partitioning can take, 
some of which are introduced below. 



1.3.1 Physical Partitions 

Computations can always be done more efficiently on machines that are built specifically for a particular 
purpose. For example, a machine with large and fast disks is needed for fast searching of databases, while 
interacting with a user requires powerful graphics capability. This suggests a physical partitioning by putting 
particular operations onto specially built machines. 

Partitioning has a long history in the field of computer graphics. Due primarily to the high cost of 
hardware, graphics systems of the 1960's consisted of relatively powerless graphics devices connected directly 
to relatively large-scale computers, either single-user or time-shared. However, as the graphics devices 
became more sophisticated, tlie load on timeshared hosts, in particular, became insufferable. 

Fortunately, the minicomputers of the 1970s led to satellite graphics systems that served to offload a 
variable amount of graphics functions on to another machine [51, 55, 62, 148]. By judicious partitioning of 
responsibility between the host and the graphics device, it was possible to achieve both better response and 
higher througiiput. The more powerful tlic graphics processor, the more functions tliat could be offloaded, 
until tlie satellite system took on the appearance of the host. Taken to its extreme, this branch of evolution 
led naturally to the personal computer - completing a round on the Wheel of Reincarnation [101], as 
illustrated in Figure 1-2. 

In configuration 1 of Figure 1-2, the pnxressor directly controls the display device. In configuration 2, the 
display commands are accessed directly from the processor's memory. In configuration 3, a special dual-port 
memory hold the display commands. In configuration 4, a second processor has been added to send 
commands to the display from the display buffer. The display control is similar to configuration 1, except for 
tlie communication channel to the main CPU. At each step through tliis cycle the partionability problems 
must be addressed. In fact, the amount of distribution of function increases at each cycle. 

For the 1980' s, increasingly powerful workstiitions, together with tlie proliferation of networks, have made 
truly distributed graphics possible. The higher bandwidth of available networks, when compared to tliat of 
previous host-satcllitc interconnections, makes it even more feasible to achieve better performance by 
partitioning tlie application between machines, especially if the remote host is significantly more powerful 
tlian tlie local workstation. Moreover, it is now possible for a single workstation to have access to multiple 
backend machines, possibly simultaneously. Many of those machines may support graphical applications that 
can not be executed on the workstation - due to memory or language requirements, for example - but can use 
the workstation for output. 

On a hardware level, a given computer system may contain several different processors, and even a single 
processor may be implemented as several functional units. This is consistent with further travel on die Wheel 
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Figure 1-2: The wheel of reincarnation 

of Reincarnation model cited above. These parallel architectures provide much promise for tlic fiiture, but 
this thesis will concentrate on partitioning at higher levels. Before experimenting with partitioning problems 
into many pieces (which will be required by future hardware), we should have a good undei^tanding of how 
to partition tlicm into two pieces. 



1.3.2 Logical Partitions 

In addition to the physical partitioning tiiat may be motivated by cost and performance, experience in 
developing local area networks by the author has resulted in the realization tliat long before networks reach 
tlieir physical size limits, they usually become unmanageable once they span several bureaucratic boundaries. 
Even if the network is physically contiguous, artificial division along organizational lines is often desired. 

There is also a more fundamental logical partitioning between graphics systems and the application 
program. That is, system designers must determine which facilities the graphics system should provide and 
which the application should provide. Similarly, even when the functions ol'thc service are decided upon, the 
server may be implemented in many ways by partitioning its functions between modules or processes, for 
example. 



1.3.3 Static and Dynamic Partitions 

Another attribute of the partition is when it is performed. A static partitioning is performed once when the 
program is designed, configured, or initialized. More ambitious projects might try to partition dynamically 
during run-time. Load sharing is the usual motivation for dynamic partitioning, lliis involves migrating tasks 
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to more evenly distribute the load among several computer systems. Load sharing can be used only when the 
systems are relatively homogeneous. In this work we will deal with heterogeneous systems consisting of 
dedicated workstations and centralized server hosts. 

There have been a few attempts at dynamic partitioning in heterogeneous systems, by assigning tasks to 
either tlie mainframe or host depending on current workloads. For instance, the ICOPS system at Brown 
University attempted to perform dynamic partitioning [146, 128]. One application using die Brown 
University Graphics System (BUGS) was dynamically distributed between a mainframe and a 
minicomputer [97]. In another example, die CAGES system at die University of North Carolina automatically 
generated the linkages at compile time for distributed graphics programs written in PL/I [62]. More 
interesting would be a solution to the problem of handling multiple applications or multiple languages 
simulUincously. 

We shall see enough problems with static partitioning that it is not clear if dynamic partitioning is worth the 
cost. In either case, efficient techniques for static partitioning and effective measurements and evaluations are 
prerequisites to solving the more general problem. Without the ability to easily experiment with static 
partitioning, dynamic partitioning should not even be attempted. 

1.3.4 Total and Partial Partitions 

Unfortunately the word "partition" has taken on a fairly specific meaning in die terminology of networks. 
It usually refers to a single network that is divided into two or more totally disconnected smaller subnetworks 
because of a failure of one or more components. A typical example of Uiis kind of partitioning involves the 
failure of several links or a gateway, causing a network to divide into disconnected parts. It is desirable to 
continue functioning as much as possible within each network partition. 

However, if Uie disconnected subnetworks never reconnect, then the problems are just the same as Uiose of 
several smaller networks in isolation. The interesting situations occur only when the parts are reconnected, 
and information flows again between the parts. Experience with tlie Stanford University Network has been 
that in reality slow or partial degradation is much more common than total failure. 

This thesis concerns itself only with the information flow between the parts of a connected system, not die 
details of recovery from link errors after total partitions. A partial partitioning, in which communication 
between the parts is possible but more costiy than communication within each part, may be inevitable or even 
desirable. Additional reasons for this will be discussed in in Chapter S, in particular the sections on future 
computing system organizations. 

1 .3.5 Protocol Design: the Result of Partitions 

Many critical choices must be made when designing die protocols or interfaces between the parts of a 
distributed system. The protocols should be at a high enough level to make the communication efficient, but 
flexible enough to allow for most users' needs. The designer must anticipate the degree of functionality tliat 
users will want, and provide enough services to achieve diat functionality, or else the system will be too 
restrictive to luc. At die same time, if the service provides too many features, or requires too much interaction 
with the client, the performance will not be adequate. This diesis evaluates die protocol choices made in one 
design of a distributed graphics system. 
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1 .4 Overview and MajorContributions 

The spectrum of roles for graphics workstations from fixed-function terminal to self-contained personal 
computer was examined in tliis chapter, along with motivations for the study of die partitioning problem for 
distributed graphics systems. The next chapter discusses three different approaches to related problems: 
traditional standard graphics packages, object-oriented window systems, and virtual terminal management 
systems. Chapter 3 presents the Virtual Graphics Terminal Service architecture in fairly abstract terms. In 
particular, tlie protocol between the server and a client application program is specified. Chapter 4 describes 
a prototype implementation of the Virtual Graphics Terminal Service, the VGTS user interface, and a sample 
application program. Chapter 5 investig^ites some issues involved in partitioning of function, the rationale 
behind the choices made in tlie VGTS design, and some simple performance models to motivate experiments. 
Chapter 6 gives tlie results of tliese measurements, and discusses die cost/pcrfonnance tradeoffs. Finally, 
some conclusions and directions for future work are drawn in Chapter 7. 

Although many people were involved in the development of Uie VGTS, this thesis concentrates on tlie 
following major research contributions by the audior: 

1. The virtual terminal concept was extended to support graphics by incorporating support for 
structured display files, as well as conventional textual interaction. The abilities of virtual 
tenninals to support multiple distributed applications are combined with the power and 
portability of structured display files. 

2. The application interface for defining graphical objects was specified and implemented separately 
from die user interface for viewing those objects. Both die advantages and disadvantages of this 
strict separation are discussed. 

3. The protocol used for defining objects was extended transparendy across networks using several 
transport protocols, resulting in distributed graphics programs. These programs were actually 
used, so performance constraints were stringent. 

4. Measurements were performed to deteiinine Uie efitct of various factors on performance of 
graphical applications. The measurements verify that performance is insensitive to network 
bandwidth, but depends heavily on CPU speed and protocol characteristics. Using staicturc 
provides important speed improvements in some cases, but other basic factors such as inner loop 
optimization and proper batching of requests make even larger differences. 

The results show Uiat die VG'FS is suitciblc for a large class of applications, and can be used as a basis for 
much further research. 
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Related Work 



This chapter compares the evolution of three separate kinds of systems related to distributed graphics, as 
illustrated in Figure 2-1. The arrows in this Figure arc drawn in tlie direction of control flow. The first and 
oldest line of development is the traditional standard graphics package, with tlic application programmer in 
control over a graphics library. The second deals with so-called "object-oriented window systems" for 
personal workstations with tlie user in ultimate control. Finally, a third concept, virtual terminals, combines 
both other approaches, with the user in control of the viewing process while the applications control the 
objects being displayed. 
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Figure 2-1: Three kinds of approaches 



2.1 Standard Graphic^ Packages 

It is important to examine the long history of Computer Graphics to discover what functionality has been 
determined to be important. Although many efforts have involved ad hoc systems to. produce a particular 
picture or support a particular device, several st^uidard efforts are more promising for our needs. Although 
we arc concerned with distributed systems for workstations, standards have tlie advantage of making graphics 
software more readily available. Standards should also be studied so the common concepts and tei minology 
can be developed to compare different approaches. 

Farly graphics systems were usually "packages" of functions called by application programs. The few 
dominant manufacturers of graphics devices, such as Calcomp and Tektronix, established de facto standards 
until the 1970s [76]. Users first would link a program with the appropriate object library. When the program 
was executed it would read some input data and produce output through the graphics functions. Since 
graphics devices were expensive, a package was usually concerned with one kind of device. If the user wanted 
output on another device, either the program could be linked with another version of the graphics library, or 
tiie library would handle several possible graphics devices at run-time. 

These types of graphics systems are most common since they have been in use for many years, and thus are 
the subject of many standardization efforts. Figure 2-2 gives an overview of the interfaces between 
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components of traditional graphics paclcagcs. At the highest level arc application databases where models are 
stored. One standard database format is called iGiiS for Initial Graphics Exchange Standard [3]. This is a 
common database format to allow a user to exchange computer aided design data between systems of 
different manufacturers. 
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Figure 2-2: Standard graphics package interfaces 

The application's interface to the graphics system has seen tlic largest amount of standardization, witli many 
similar but incompatible standards for this level such as GKS, CORii, PiiiGS, and others, to be described in the 
remainder of this section. Some attempts at lower levels of standardization include: VDI, between the 
graphics system and the device driver, and NAPIPS, between tJie device driver and the device. 



2.1 .1 The SIGGRAPH CORE Graphics System 

The ACM Special Interest Group on Graphics (siggkapii) Graphics Standards Planning Committee 
report, commonly known as CORI-, has become widely used as a model for graphics systems [147]. One major 
motivation for this standardization attempt was the undesired distinction made at diat time between directed 
beam (vector refresh) graphics devices, and storage tube (and hard copy) devices. The utjportance of device 
independence was emphasized at the 1976 Computer Graphics workshop in Seillac, France [60]. This 
workshop attempted to unify the treatment of tlic two kinds of graphics devices, and formed a basis for many 
subsequent graphics packages such as CORE. 
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2.1.1.1 Device Indiependlence 

Hard copy and storage tube devices have a simple physical concept of a current location. For example, in a 
pen plotter the location of the pen was obviously visible. A sequence of move and draw commands was the 
most natural way to think of how a pen plotter created a picture. The CORE system extended tliis move and 
draw concept to three dimensions, using a synthetic camera analogy. Other state information such as the 
color or size of the pen, was also extended into tlic CORE system. The application constructed a model of the 
object in its own internal data stmctures, and would use tlie graphics package only for viewing operations. 

On the other hand, directed beam graphics devices usually had display lists, which were traversed 
repeatedly to display the picture. Changing one element in the display list would instantly change the item 
being displayed, while storage tube and hard copy devices would be erased and redrawn completely for any 
modifications besides additions. CORE used the concept of segment to represent this retained graphics 
information. 

2.1 .1 .2 Coordinate Systems 

Another important contribution of CORE was the understanding of the importance of different coordinate 
systems. The Core System and most other subsequent graphics packages deal with tliree coordinate systems: 

1. World Coordinates (WC) are arbitrarily defined by the applications programmer. In CORE these 
are floating point numbers in either two or three dimensions. 

2. Normalized Device Coordinates (NDC) arc used to define a uniform coordinate system for all 
display surfaces. In Core these are two dimensional floating point numbers between zero and 
one. 

3. Device Coordinates (DC) represent the actual units used by the display device, usually unsigned 
integers of ten to sixteen bits. 

Core implementations map from world coordinates to normalized device coordinates, with a driver for each 
device mapping from normalized device coordinates to actual device coordinates. This allows most of the 
graphics package implementation to be retained when new graphics devices are introduced. 

2.1 .1 .3 CORE as a Standard 

The Core System was defined as a set of language-independent functions, with the mapping from the 
abstract function names to programming language identifiers left: undefined. This resulted in 
implementations that were incompatible in many details, altliough system models and basic concepts were 
fairly consistent across most implementations. 

Although the CORi- system was proposed in 1977, and was revised in 1979, in five years it has not yet 
become an official standard, and may never become one, due to the success of Ruropean sUindardization 
efibrLs. '['here has been much more experience in the nreas of portability and device independence since the 
1979 report, as well as some reconsideration of the way modeling and viewing were separated in CORi:[133]. 
Since these issues are also important in a distributed system, the C0RI«: system was not suitiible for our work. 
However, CORE influenced subsequent standardization attempts, described in the next sections, tliat have 
overcome some of its problems. 
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2.1 .2 The Graphical Kernel System 

The Graphical Kernel System [64] has become a popular standard that started in Europe with the German 
DIN (Deutches Institute ftjer Normung) and spread to America. German standards are specified and 
adopted more quickly than American standards because DIN is a government body while ANSI is a volunteer 
organization requiring the consensus of competing industrial representatives. Although they are intended to 
be as close as possible, there are some slight differences between die ISO GKS and American National 
Standards Institute Committee on Computer Graphics Programming I..anguagcs (ANSI X3H3) version of 
GKS. Most notably, due to the complexity of the GKS standard (which already has nine levels of subsets) 
ANSI committee X3H35 has defined a subset of the lowest level of functionality, called the Programmer's 
Minimal Interface to Graphics, or PMIG [122, 2]. 

2.1 .2.1 GKS Workstations 

GKS uses the workstation concept to represent some logical input devices and one associated output device. 
This is in contrast to Core in which only supports one view surface and does not support any relationship 
between input events from different input devices. GKS explicitly states that one application can manipulate 
multiple workstations; no mention is made of several applications sharing a single workstation. The idea of 
placing the I/O devices on a physically separate machine from the one running tlie application program was 
one of tlie original motivations for the workstiUion concept [48], but most implementations of GKS have run 
on only one machine. Section 2.1.2.7 will discuss the problems involved in a distributed GKS 
implementation. Ihe distribution capability has some subtle but important effects on the structure of GKS. 

2.1 .2.2 GKS Output Primitives 

The graphics primitives used in GKS, similar to those in Core, arc the following six: 

1. Polyline: A set of connected lines drawn between a list of points. 

2. Polymarker: Symbols of one type are centered at given positions. 

3. Text: Character strings are drawn at a given position. There are many attributes to control die 
orientation, spacing, and justificationof text. 

4. Fill Area: A polygon which may be filled with a uniform color, pattern, or hatch style. 

5. Pixel Array: An array of pixels with individually specified colors or intensities is displayed. 

6. Generali/ed Drawing Primitive: A set of points is transformed and passed through to the device 
dependent driver. 

The generalized drawing primitive is intended to take advantage of special functions of the workst«ition, such 
as the ability to draw arcs or curves. Note Uiat there is no notion of current position as in Core, and 
operations are in two dimensions only. Three dimensional extensions are currently under development. 

2.1.2.3 GKS Attribute? 

Abstracting slightly from the hard-copy analogy, GKS and Core retain current values for each of several 
af tributes, representing tlie state of tlie drawing device used for relevant output primidves. Thus, although the 
notion of current position docs not appear in GKS, the stiite variables necessary to simulate a drawing device 
are still needed. For example, the polyline primitive has line-type (solid, dashed, etc.), width, and color 
attributes. Hcjwever, in GKS bundle tables can be used to group attributes. Instead of specifying every 
attribute on every output primitive, an index into the bundle table (a small integer) is specified, and die table 
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gives values for all tlie attributes. For example, instead of specifying a color absolutely everywhere it is used, 
it could be defined only once to simplify changes. 

2.1 .2.4 GKS Segments 

GKS segments arc named with integers specified by the application. Segments may be transformed, made 
visible or invisible, highlighted, ordered from front to back, deleted, renamed, and inserted into other open 
segments. Rvery primitive within a segment can have an attribute called the pick identifier which estiiblishes a 
second level of naming for use with the picic input device. However, the primitives within a segment cannot 
be modified; the pick identifier serves only to distinguish parts of a picture used for graphical input. ITiere is 
an explicit fimction to set tiie pick identifier. All primitives added to the segment until the next call to this 
function will have the same pick idendfier. 

In GKS segments can be posted on actual workstations, called Workstation Dependent Segment Storage or 
Wdss. In addition segments can be sent to Workstation Independent Segment Storage (Wiss). Segments can 
be moved back and forth between Wiss and Wdss (actual workstations) under control of the application 
program. 

2.1 .2.5 Graphicallnput iin GKS 

The concept of logical input devices was used as a basis for extending device independence to graphical 
input in GKS as well as Corf, [152]. The CORfi system treated input and output functions as orthogonal 
concepts, so, for example, the selection of view surfaces had no effect on echoing. On the other hand, GKS 
asscx:iates logical input devices with workstations. GKS provides tlie following classes of input devices: 

Locator Provides a position in world coordinates and a transfonnation number, detennined by the 
viewport in which the input occurred. A trackball or joystick is the typical locator device. 

Stroke Provides a scries of positions in world coordinates and a transformation number. 

Valuator Provides a single real number scalar value, from a one-dimensional device such as a rotary 
dial. 

Choice Provides the ability to choose among alternatives, like the button device in CORO. A non- 
negative integer indicates a selection, and zero indicates no selection. 

Pick Provides a pick status, a segment name and a pick identifier (the item "picked"). Primitives 
outside segments cannot be picked. The typical pick device is the light pen, which senses 
when the beam of a CKY passes over the point underneath its tip. 

String Provides a character string, similar to the keyboard device in CORE. 

'file original GKS specification did not have the stroke device class, since it can easily be built on top of other 
primitives, given a suitable semantic model of input devices [U3]. 

At any time a logical input device is in one of three modes: 

Request Allows tlic input device to accept request commands. When the application issues a request, GKS 
waits until input is entered, or tlie operator enters a break action. Control is then passed back to 
the application. 

Event GKS maintains an event queue. An event report on this queue contains the logical device 
number and a value from that device. Invents are generated asynchronously by operator action. 
An application can wait for an event, remove it from the queue, or fiush events from the queue 
without reading them. 
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Sample Allows the input device to accept sample commands. Sampled devices do not cause events on any 
queue, but are instead polled by the application. When the application issues a sample command, 
GKS returns the current value of the device without waiting. 

2.1 .2.6 GKS as a Standard 

Like Core, GKS was defined as an abstract set of operations instead of a particular interface in a particular 
programming language. However, efforts are underway to standardize language bindings, so there is a greater 
chance that GKS programs can truly be portable. A Fortran binding is included in die ANSI standard, and 
work on other language bindings such as C [114] is underway. Unfortunately, even these standard binding 
efforts are hampered by the many different dialects of these languages. 

Full GKS (highest levels for both input and output) includes 110 functions plus 75 inquiry functions. The 
lowest level of ISO GKS requires 52 functions plus 38 inquiry functions. The lowest level of ANSI GKS (no 
input) requires 31 ftinctions plus 17 inquiry functions [122]. Of course, counting the number of functions is a 
very coarse measure of complexity, but by most measures GKS seems to be a much simpler system to 
implement tlian CORE. There are proposals for 3D extensions to GKS, since this lack is the major reason why 
American groups like SiGGRAPii oppose the standard. 

2.1 .2.7 A Distributed Implementation of GKS 

One of the principle advantages of GKS for distributed workstation-based systems is the ability of the 
workstation concept to allow potential distribution. A recently-announced product called nova*gks is an 
implementation of GKS tliat can be distributed across several machines, but still allows only one application 
to be run at a time, and handles only one host at a time [149]. Nevertheless, nova*GKS can be examined as an 
example of a distributed graphics system using GKS. The nova*GKS implementation consists of four major 
layers: 

1. GKS Interface - provides ihe functions specified in the GKS standard, implemented as modules 
tiiat are linked with an application program. 

2. Workstation Manager - handles device independent aspects of workstations, including 
workstation independent segment storage (WiSS). 

3. Workstation Supervisor - provides software simulation of GKS functions that arc not directly 
supported by the physical workstation or the device driver. 

4.. Device Driver - low level device driver, which implements the graphics primitives and maps into 
device coordinates. 

Between each set of layers, an interesting coupling scheme is used. Instead of directly calling tlie functions in 
tlie lower level, all accesses must funnel down through a single lower level supervisor function. The lower level 
supervisor can then either be a large case siatcmciU which fans out to all the appropriate lower level 
modules, or it can encode the functions over a communication line to a remote processor, where the fan-out 
then takes place. Thus the choice of where the communication t<ikes place and even tlie kind of protocol used 
can be done at link-time widi no changes to die rest of tlie package. 

2.1 .2.8 Adding Structure to GKS 

Proposed GKS output level 3 supports structured segments [130]. The later Chapters of this thesis provide 
evidence tliat structured segments provide performance increases in a distributed environment. As the name 
implies, this proposal is upward-compatible with tlic other levels of GKS. The main addition is the ability of 
segments to call other segments. An existing segment can be reopened for editing, and elements can be 
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inserted and deleted. Editing is performed using an element number, an integer count of elements within a 
segment. For example, tlic first element in a segment is number 1, then 2, etc. It is not clear what happens 
when an element is added or deleted from the middle of a segment - probably all the elements change their 
numbers, leading to possible confusion. For this reason labels may be used to refer symbolically to elements 
instead of using their numbers. Labels are known only within a segment; separate external names are used to 
name whole segments. 

The transformation of each primitive is the concatenation of all segment transformations of the ancestors of 
the primitive. Thus a stack of matrices is stored, starting with the identity transformation, multiplying the 
current matrix by the call transformation matrix and tlic called segment transformation matrix, and pushing 
tlie result onto the stack for each segment, starting with root segments. 

The contents of segments can retrieved, and segments can be stored on meuifilcs. There is a call to write 
private data to the segment, which seems to indicate a desire to use the segment facility as an application 
database. A totiil of 15 new functions are added to GKS for this level, so the complexity of GKS is increased 
only slightly. However, run-time overhead could be significant, since a total of 29 attributes (in addition to 
die transformation matrix) are pushed and popped during each segment traversal. The GKS output level 3 
proposal was a reaction to tlic PiiiGS effort to be described next. The principle advantage is compatibility 
with many GKS iniplemcntations and applications currently being built. 

2.1 .3 The Programmer's Hierarchical Interactive Graphics Standard 

A more recent standardization effort has produced the Programmer's Hierarchical Interactive Graphics 
Standard (PlUGS)[4]. As its name implies, PlilGS allows arbitrarily deep hierarchical specification of 
graphical objects, instead of the less general segmentation mechanism in Core and current GKS. One of the 
staled reasons for tliis more elaborate structure of objects is the increased effectiveness of making changes to 
the display in support of interactive graphics. An important design criterion was to provide adequate 
perfonnancc in interactive applications, by taking advantage of today's more powerful graphics workstations. 

Hie actual display primitives in PlllGS are similar to those of GKS, altliough tliey appear in a more 
elaborate framework. Jliere arc both 2-dimensional and 3-dimensional functions. Display primitives, along 
with attributes, viewing operator, modeling transformations, and references to other structures, can all be 
elements of a structure. Structures can be edited, by deleting and inserting elements. 

PlilGS includes die concept of workstations, but workstations do not logically store tlic graphics data. An 
application program defines a picture by adding entries to tiie device independent structure database. The 
workstation driver then reads tlie database to cause the physical terminal screens to be drawn. Each 
workstation has at most one fixcd-si/.c rectangular viewing surface, and may have any number of input 
devices. Workstations have descriptor tables that describe the capabilities of the workstation. The 
applications program can inquire about which capabilities are available and adapt accordingly. Although 
programs written using this feature can work on several diffcreiU types of worksUitions, the application 
programmer must anticipate ail possible configurations when the program is written. 

Fxich attribute corresponds to a "register" of a virtual workstiition; these registers are changed by commands 
in the header of each stmcturc, and objects are rendered in the color that is in the registers at the time of the 
rendering. Unfortunately this introduces much complexity in the device driver, because it must keep track of 
tlic state of all of these virtual registers. 
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2.1 .4 The LBLNetworkGraphics System 

The Network Graphics System was developed by Lawrence Berkeley Laboratories as an extension of CORE 
for a network environment [24]. Although this is an on-going development effort, as opposed to a proposed 
standard, NGS is similar in spirit to Phigs. Like GKS and CORE, it was designed for vector refresh and 
storage tube devices, and later extended to raster devices. 

ITie Network Graphics System allows die definition of hierarchical structures, which can be deleted or 
appended, but not otherwise modified [25]. Attribute information is stored separately from the object 
definitions, so it can be changed dynamically. Attributes can be bundled, or controlled explicitly and 
individually. Even diough bundling capability is provided, the authors state that direct control is expected to 
be used most often. 

2.1 .5 Virtual Device Interface and Metafile 

Since most graphics packages use some form of normalized device coordinates, this is another logical 
candidate for a standard partitioning point. The graphics package can be written in terms of a virtual device, 
which is then implemented on the physical device. The Virtual Device Interface specification (VDI) is yet 
another graphics standardization effort of ANSI committee X3H33 [7]. As shown in figure 2-2, the Virtual 
Device Interface specifies the low level target for graphics packages. The Virtual Device Metafile (VDM) 
standard [5], similar to that developed at Los Alamos National Laboratory [110], is an encoding of the Virtual 
Device Interface into a stream of bytes to be stored on a file. 

As indicated in Figure 2-2, die VDI specification could be realized in a real device, or at least a "black box" 
which the user treats as a hardware device. The device drivers would be written by the manufacturer of the 
graphics device, instead of the author of the graphics system. Since the VDI specification is precisely defined, 
it should be possible to put the implementation of the the virtual device on a different machine Uian die one 
running die graphics package. Unfortunately, this interface involves botli a high frequency and large amount 
of information interchange. Thus it may not be suitable for partitioning when communication costs are high. 

2.1 .6 Videotex and Teletext Systems 

Other systems have been developed for situations with high communication costs between the graphics 
system and the device. Examples diat deal witii partitioning are Videotex and Teletext. Videotex is an 
interactive communications service that delivers color graphics information from centralized databases. Tliis 
information is most often delivered over telephone lines, decoded by a dedicated hardware device, and 
displayed on a television monitor. Thus, videotex is intended for direct use by consumers, combining two of 
the most familiar pieces of electronic equipment in most homes today: the telephone and the television set 
In addition to providing information, videotex allows users to perform transaction such as ordering products. 
One of the major standards in Uiis area is the North American Presentation Level Protocol Syntax 
(NAIM I'S) [6]. Since telephone companies in lunope are generally smaller and run by the government, there 
have already been several videotex systems in operation in Britiiin (l>Ri;sri:L) and h'rancc (AN l l lOPlO. 

Teletext is a similar technique designed to bring informadon service to home consumers. However, teletext 
uses one-way broadcast transmission, often dirough cable television systems. The major standard in tiiis area 
is die North American Broadcast Teletext Specification [11]. 'Hiis standard specifies exacdy how die messages 
are encoded for transmission, which are Uie lower levels (physical to transport) of protocols. The data can be 
transmitted on standard television channels, during die vertical blanking interval, or entire channels can be 
dedicated to teletext. The presentation level of nab i'S is naplps. 

Unfortunately, since dicse protocols arc directed to a consumer market, dicy arc limited in dieir abilities. 
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For example, they are often tied to specific common video resolutions that are lower than typical scientific 
workstations. More importantly, they are intended for very inexpensive terminals, so they would waste die 
power of most modern workstations. In particular, they handle only one activity at a time. Since wc are 
interested in future computing systems that contain multiple processors executing concurrently, wc will next 
examine systems that can manage this concurrency. 

2.2 Object-Oriented Window Systems 

The desire to use graphics as an aid to user interface has led to the development of object-oriented window 
systems. In these systems, there might not be application programs, per se, but rather objects tliat respond to 
the control of the user. An interesting paraphrase of the object-oriented window system philosophy is "don't 
call us, we'll call you". Tliat is, instead of the application program calling fi.mctions in the graphics package, 
tiie graphics system calls user-defined ftmctions to display themselves when needed. This mechanism, the 
graphics system calling client software, is referred to as an up-call, in contrast to down-calls of traditional 
graphics packages. 

This difference in control reflects the different application areas for which these systems were developed. 
The graphics systems discussed in the previous section consider the picture to be the main purpose of the 
program. ITius they are suitable for application areas such as commercial animation in which realism and 
precise control of the picture are most important. However, many programs are intended to perform, some 
other function, with graphics as a side-effect. For example, the principle function of an integrated circuit 
editor is to edit integrated circuits, not to draw beautiful pictures of them. In fact, the information being 
displayed by programs is often abstract, so "realism" is meaningless in these cases. 

2.2.1 Smalltalk 

Smalltalk is a scries of languages based heavily on graphics with an object-oriented window system [58]. 
The language was first designed as a tool for research by the [.earning Research Group at Xerox Palo Alto 
Research Center. In their view, the ideal system would use powerful yet compact and portable "personal 
dynamic media" which students could use and interact with [90]. The ideal pcreonal dynamic media was 
called the dynabook, and corresponds to a futuristic view of today's graphics workstations. 

A Smalltalk system is composed of objects, which consist of some private memory and a set of operations. 
The programmer specifies these operations as methods that are invoked when objects receive messages. 
Advantages of such an approach include extensibility; applications can define their own graphics objects and 
primitives because screen updating is controlled by die application itself. On the otiicr hand, the programmer 
can declare a class to be a subclass of another clasjj, so tliat operations are inherited. Only Uie new operations 
have to be defined, so the extensibility am be performed without much programming overhead. 

2.2.1.1 The Smalltalk Environment 

Smalltalk is a graphical, interactive programming environment. One key aspect of the user interface of 
Smalltiilk is the use of a pointing device such as a mouse to select items instead of typing commands [50]. 
Many of tliese ideas originated in the NLS system at Stanford Research Institute by Englebart and others 
during die late 1960s and early 1970s [49]. Although NLS was used only witiiin SRI, the system is now called 
Augment and marketed by Tymesharc corporation. 

Smalltalk, unlike Augment, is intended to be implemented on self-contained personal computers which 
include a single large address space and a disk. Unfortunately, implementations of Smalltalk on commercial 
microcomputers have failed due to the performance problems of small processors and storage devices. One of 
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the few machines that can run Smalltalk with adequate performance is the Dorado, a very high-performance 
and expensive scientific computer developed at Xerox PARC [75]. Workstations are becoming more 
powerful, but machines in the class of the Dorado will be expensive for some time to come. Although using 
the object-oriented approach of Smalltalk at all levels may not be desired, the user interface advances are 
being adapted to other systems. 

2.2.1 .2 Smalltalk User Interface 

The user interface of a Smalltalk system typically consists of several Views of objects on a gray background. 
The name "window system" comes from the appearance that these views arc "windows" into tlic world of 
objects. The user controls a small arrow called a cursor by moving the pointing device. Directing activity to a 
particular piece of information in a view is done by making a selection. The system provides immediate visual 
feedback to indicate the selection. For example, the selection is often displayed complemented (black to 
white and white to black). At any particular time, only one view is selected, indicated by a complemented 
tide, and appearing to lie on top of any other overlapping views. 

Pop-up Menus are also used to select commands. In response to a user action such as a button press, a list of 
commands appears underneath the cursor. While the button is held down, the cursor is moved to select one 
of the commands in the menu. When the button is released, the selected command is carried out. Some 
command menus are particular to die object being displayed in the selected view, while other command 
menus are uniform across the entire system. Similar powerful user interfaces have been incorporated into 
other object-oriented single language integrated environments, such as on tlic New Window System for the 
Symbolics Lisp Machine, through a language extension called Flavors that provides objects with inheritance 
of operations from multiple super-classes [157]. 

2.2.2 "Lisa Technology" 

The Star word processing system by Xerox corporation [124] incorporated many of these object-oriented 
ideas into a commercial product using tlic fairly conventional programming language Mesa (87). The Star 
system used an analogy between the graphics screen and a conventional desk top. The screen contained icons^ 
small symbolic images that invoked actions when selected by the mouse. For example, moving a document to 
a filing cabinet icon caused it to be stored in a file server, while moving it to a printer icon caused it to be 
printed. The Stiir developers claimed that interfaces using icons were easier to learn and less error-prone than 
conventional textual command languages. 

The Cedar Viewers System [92] was developed at the Xerox Computer Science laboratory for their 
prototype software development environment called Cedar [46, 140]. The Cedar environment was intended 
to combine the best features of InterLisp, in particular the Programmer's Assistant [139], with the Mesa 
program development environment [99]. The application program specified procedures to be called in 
response to input events. These procedures used the Cedar Graphics Package to draw die objects they 
represent on the screen when requested [I54J. 

Unfortunately the Star system suffered from slow icsponsc times, and the Cedar system required very 
expensive computers such as the Dorado to run eflectivcly. Similar user interface functionality was made 
available for much lower cost with the introduction of die Apple Lisa and Macintosh computer systems [159]. 
The Lisa and Macintosh software borrowed the desk lop metaphor from Star, with icons representing data 
objects such as documents. Since these machines were the first to gain widespread attention, such systems 
have been called examples of "Lisa Technology". Lisa was intended as a low-cost office personal computer, 
so its performance was also fairly slow, with some operations t<»king 30 seconds. This was due, for example, to 
swapping of several megabytes of object code into a physical memory that was only expandable to one 
megabyte. 
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2.2.3 Other Window Systems 

An important research effort has been the Canvas system [13], and its successor, called Sapphire, developed 
at Carnegie-Mellon University for the Spice project. Sapphire (Screen Allocation Package Providing Helpful 
Icons and Rectangular Environments) provides a virtual bitmap which applications can manipulate any way 
they wish [95]. Applications can specify exact location and shape of the windows, or be notified when location 
and shape is changed. Each window can be transparent, or can take responsibility for remembering what it 
obscures. For example, pop-up menus are implemented as windows. 

Some of the user interface ideas of object-oriented window systems have been implemented on traditional 
text-only [158, 65] or vector display terminals [89], although a full bitmap display is desirable, and becoming 
more prevalent, especially in research environments [23]. More important is the requirement of shared 
memory for the many procedure calls in this approach. Some systems have extended tlie up-call concept with 
remote procedure calls, with inconclusive performance results [59]. 

2.3 Virtual Terminal Management Systems 

As we have seen in the last two Sections, graphics packages put the application in control, while object- 
oriented window systems put tlie user in control. This distinction between main-stream standardization 
efforts and tlie window system line of development has only been touched upon in the literature. Partly this is 
because of the delay involved in standardization efforts; the current standards were designed for hardware of 
more than ten years ago. Since tlie workstation-based distributed systems described in Chapter 1 did not exist 
ten years ago, these standards do not easily lend themselves to a distributed environment [9]. 

One of the few efForte to combine these two lines of development was a window system for a storage tube 
display [1 15]. The basic observation from this work was that tlie advantages of the two approaches can be 
combined if the problem is viewed as one of resource management. Since a major role of an operating system 
is to manage hardware resources, recent research in resource management by operating systems, in particular 
the management of terminal systems, should be examined. 

2.3.1 Network Virtual Terminals 

The name "virtual terminal" was first used during the development of protocols for long-haul networks 
[43]. Problems arose due to tlie large number of different operating systems and terminals that needed to 
communicate in the network. If tlicre were n types of terminals and m types of operating systems, tiicn nxm 
terminal handlers were needed. This led to very large software costs as networks diversified. 

Instead of forcing each computer system to handle all possible types of terminals, each could handle only 
one abstractly-defined network virtual tenninal. The conversion from virtual to real terminal would be 
performed by the machine to which the terminal directly connects. This is similar to the virtual device 
approach described in the previous section, also used to provide device independence. As workstations 
become more powerful, they can be considered as nodes in a network, and tlic virtual to physical terminal 
translation could be performed by workstations. . 

2.3.2 Rochester's Intelligent Gateway VTMS 

Another advantage of the virtual terminal concept is the support of multiple applications simultaneously. 

Traditional graphics packages described in the fii-st section of this chapter assume one application is in total 
control at any time. Although the window systems discussed in the previous section display multiple contexts, 
usually only one application is active at any time on the personal computer. One of the first attempts to use 
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multiple concurrent processes in multiple windows for program development was a system called 
Copilot [136]. The ability to monitor concurrency naturally through a window system has been determined 
by the author to be invaluable in a distributed environment. 

Rochester's Intelligent Gateway was designed to provide a uniform user interface to manage distributed 
resources [78, 79]. The Rig Virtual Terminal Management System (VTMS), was one of the earliest systems to 
provide simultaneous access to multiple, possibly distributed applications [77]. VTMS mapped any number 
of virtual terminals to a physical screen simultaneously, and each virtual terminal could be written to or 
queried for input by applications throughout the distributed system. 

In RIG tiic resource management problem was viewed fundamentally as a problem of process 
management, with requests sent to server processes through messages. Table-driven command interpreters 
were also provided to enforce a consistent user interface across different tools. These contributions 
significantly influenced many subsequent efforts, including the research described in this thesis. However, 
VTMS did not provide graphics support, nor did it provide effective terminal emulation. 

2.3.3 Apollo Domain 

The Apollo Domain workstation-based distributed system uses some of the concepts of virtual terminals as 
developed in VTMS [8]. Domain also provides a distributed file system, and other distributed objects. 
However, its architecture applies to only one particular manufacturer since die network transparency is 
handled at a very low level: demand paged virtual memory. Since most research computing environment are 
very heterogeneous, Domain cannot be used to solve all partitioning problems [37]. 

2.3.4 The Virtual Graphics Terminal Service 

The extension of the virtual terminal concept to graphics is the subject of the next two chapters. The system 
described here is called the Virtual Graphics Terminal Service, or VGTS^ the name reflecting the VTMS 
conceptual base [81]. The VGTS takes an approach different from Domain's, handling transparency at a 
much higher level: abstract operations. This allows operations to be partitioned between machines of very 
different architectures running different operating systems, and using vastly different network technology. 

The VG'I S interface to the programmer is much simpler than most of die systems discussed in this chapter. 
For example, tlie NGS working design document [25] has a partial list of 181 functions, while tlie VGTS 
programmer's interface is about 30 functions. Of course these other systems may provide more functionality 
in some areas, but it is not clear Uiat this functionality is always necessary. 

The next two chapters will provide more details on the architecture and implementation of the VGTS, 
including more comparisons to both standards and window systems. Chapter 5 will examine these types of 
design trade-offs in depth. 
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Architecture of the VGTS 

As we have seen in the last two chapters, the functional partitioning problem is an important one that is not 
adequately addressed by either traditional graphics packages or window systems. In order to perform 
experiments on the partition of function we have first designed an architecture for a distributed graphics 
system, as described in this chapter. Only the architecture is described here; an actual implementation is 
described in Chapter 4 and rationale for the design is given in Chapter 5. 

3.1 The Environment 

No single design will be appropriate for every circumstance. It is important to limit the scope of the 
anticipated environment because most systems diat try to do everything for everybody, end up not doing 
much well at all. This section describes tlie particular environment for which the VGTS was designed. 

3.1 .1 The Stanford University Network 

The VCjTS architecture was designed within the context of the Stanford University Network (SUN). SUN is 
a rapidly evolving environment consisting of: 

• graphics workstations, such as the Xerox 1100, Symbolics 3600, Sun [15] and IRIS [39]; 

• standard timesharing systems, such as DF.cSystem-20/ToPS-20, Vax/Unix, and Vax/VMS; and 

• dedicated server machines, for high quality and high volume printing, file storage, terminal 
multiplexing, and gateway services; 

interconnected by various local networks, including about 25 different Hthernct segments [94]. Various 
machines are also connected to long-haul networks such as the ARPANirr, either directly or tiirough gateways. 
This fits the general model illustrated in Figure 1-1. 

Sun is representative of many works/a lion- based disfribuled systems currently in place or being developed 
throughout tlic computer research community [14, 119]. These systems typically provide die equivalent oft 

• powerful workstations with: 

o a general-purpose processor (1 MIPS or more) 

o a large local physical memory (1 MByte or more) 

o a high- resolution raster display (1000 by 1000 or more pixels) 

o a large virtual address space (> 20 bit) 

o a graphics input device (such as a mouse) 

o an optional disk 

each usually dedicated to a single user at a time; 

• a fast (> 1 MHz) communications network that will link the workstations; 

• a number of dedicated processors providing printing, file storage, general computation support, 
and other services; and access to timesharing or special-purpose computers and to long-haul 
computer networks. 

The architecture wc are about to describe is well-suited to any such system. 
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3.1.2 The V-System 

The software environment used for this research is called the V-System. Logically it consists of a 
distributed kernel and a distributed set of server processes. The distributed kernel consists of the collection of 
kernels resident on the participating machines. Communication within a single graphics workstation is via 
fixed-size synchronous messages, using the V kernel [31, 32]. These message semantics were originally 
developed in the Thoth [29] system and later used in Vcrex [30]. The individual kernels are integrated via a 
low-overhead inter-kernel protocol (IKP) that supports transparent interprocess communication between 
machines over a local network [164]. 

Servers include network servers, storage servers, executives (command interpreters), and, of course, virtual 
graphics terminal servers.^ The V-System software architecture is especially tailored to communicate with 
existing timesharing operating systems such as Unix, VN'IS, and Tqi'S-20. A user-level program called the "V 
sei'ver" runs on the timesharing machines and implements the V inter-kcmel protocol. Programs mnning 
within the V environment can tlien access file service or remote execution of programs transparently on the 
timesharing hosts as well as the workstation. Other protocol architectures like IP/TCP [106] and PUP [19] are 
also used to communicate with dedicated servers and larger or more remote time-sharing machines. 

The V-System architecture was designed to allow flexible interconnection, similar in nature to hardware 
organizations. Consider an operating system kernel as a bus, which provides a standard interface to connect 
modules. In computer hardware, Uie bus is usually a simple, passive device. The V-System takes into account 
multiple busses in both its hardware, as seen in Figure 3-1, and its software, as seen in Figure 3-2 [80]. The 
striking similarities between die hardware and software organizations are intentional. Note tiiat busses 
correspond to eitiier operating system kernels (usually small and synchronous) or network protocols (larger 
and asynchronous). Hardware modules correspond to software processes in this analogy. 
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Figure 3-1 : Hardware organization of the Stanford V-System 

Bus adapters correspond to network server processes, which can also be considered protocol converters. 
One major reason for hardware bus adapters is Uie availability of many peripheral devices for certain old 
busses. 'Ilic adapter allows the use of the old peripherals on new systems, without the need to redesign all the 
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Figure 3-2: Software organization of the Stanford V-System 

interfaces. Similarly, much software for older operating systems can be encapsulated and augmented in this 
model, instead of being replaced. 



3.1.3 The VGTS 

In the V-system, the worlcstation provides a virtual terminal service, similar to the VfMS in RIG [78], but 
extended to include grapliics. The VGTS acts as a multiplexor, handling requests from cJients to edit data 
structures representing graphical objects. It then uses a real terminal protocol to actually draw the objects on 
the screen. 

The following are some attributes of the VGTS which distinguish it from related work: 

• The VGTS model is declarative rather tlian procedural. Instead of describing how to draw a 
picture, the apphcation describes what is to be di'awn. The user then specifics where the picture 
should be displayed. I hus, users control physical terminals, while applications control virtual 
terminals. 

• Objects can be constmcted with hierarchical sti iictui e. An object can consist of primitives or calls 
to other objects, which can in turn be defined in terms of other symbols. This is in contrast to 
systems like GKS tliat allow only one level ol sLriictuie (usually called segments). 

• The VGTS supports tme device independent applications. There is a suindard high-level 
interface, called the Virtual Giaphics Terminal Protocol (VG'TI*) between a VG TS and its clients. 
Different terminal drivers exist for each real terminal, with tlie VGTS handling all the details of 
the real graphics protocol. 

• The VGTS implementation and interface are portable to a range of relatively high-performance 
devices. 'This contrasts with most of the object-oriented window systems that are tailored to a 
specific machine or language environment. 

• 'The VGTS supports distributed clients. Applications can run on the same workstation as the 
VG'J'S, on another workstation, or on some large computation server. Since tlie communication is 
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at a higli level, the different machines may have vastly different architectures. If the application is 
written in a suitable high-level language, the same source code is used in any location. 

• A single user can access several different applications simultaneously. The user can sv/itch 
contexts between these applications quickly and easily. Because of the ease with which 
applications can be distributed (the previous point), they can be using the local workstation or 
remote computing servers at the same time. 

These last two aspects are the major influence of the distributed heterogeneous environment on the VGTS. 
Timesharing is effective when many users must share a computing resource; since current trends indicate that 
the user is quickly becoming the most important resource, we can extrapolate the philosophy that users are 
more important than machines, and have one user being served by several different computing resources. 

3.2 The User Model 

In the modern distributed system environment, we require access to a variety of applications, distributed 
literally tliroughout the world. We would like to take advantage of the power of advanced workstations to 
provide a high-quality user interface to these resources. The ideal interface must take into account four 
fundamental principles: 

1. The interface to application programs should be independent of particular physical devices or 
intervening networks. 

2. The user should be allowed to perform multiple tasks simultaneously. 

3. The command interaction discipline should be consistent and natural. 

4. Response to user interaction should be fast 

The first principle has led to work in virtual terminals and device-independent graphics packages; the 
second to work in window systems: and the third to work in what has recently been called user interface 
management systems [143], the most common examples of which are command languages. Without adhering 
to the fourtli principle, however, much of the other work is moot. Ideally, human users should never have to 
wait for the computers: the computers should wait for the user. In a distributed environment, in particular, 
tlie supporting network protocols cannot incur inordinate overhead. 

3.2.1 The Ideal 

In view of these principles, consider the following user model. When users boot a workstiition they 
communicate with a view manager^, which allows users to authenticate themselves and initiate one or more 
activities. The activities may run local to the workstation or remote. They may be written with the particular 
workstation in mind, or run in "terminal emulation" mode. They may require 1/0 modalities other than 
traditional one-dimensional text: graphics or audio, for example. 

Each activity may be associated with one or more separate, device-independent virtual terminals (VT). A 
VT may be created by the user or by tlic activity itself. Bach VT may be used to emulate a different type of 
real terminal, for example, a page-mode VT-100 or a 3-D graphics terminal. Thus, while consistency is 
encouraged, tlie user is still able to access all resources to which he previously had access. 
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Unforlunatdy many similar systems refer to this component Ss the window manger, even though this is incorrect with respect to most 
terminology. 
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When users wish to initiate a new activity, they must fii*st create a new executive. The executive acts as a 
command interpreter from which desired activities may be initiated. Users can create a new executive, with 
an associated VT, or terminate an existing activity and W at any time, that is, totally asynchronous to any 
other activities. When a particular activity requires additional virtual terminals, it is free to create them. 
These VTs will be deallocated when the activity terminates. 

Virtual terminals are mapped to the screen when and where the user desires, hi fact, multiple screens arc 
intentionally allowed by the architecture, since in many applications color or gray-scale is desired, but high 
resolution color monitors are expensive. Thus a workstJition may have, for example, one low resolution color 
monitor and one high resolution monochrome monitor. Kach mapping of a VT to the screen is termed a view. 
When an activity creates a new VT, it prompts the user to specify the default view interactively, or the view 
manager creates tlic view automatically, depending on user preference for screen layout. Thereafter, users 
may create as many additional views as they wish. They may manipulate views of the same VT independent 
of all other views of that VT, for example, to pan or zoom die view. 

The interaction discipline across VTs (and hence activities) is as consistent and natural as possible. The 

mechanisms for moving between VTs and reorganizing the screen are standardized in tlic view manager. 
Standard editing facilities permit die user to copy text or graphics from one VT to another. A standard 
command interpreter enforces consistent command interpretation across applications. A variety of 
infonnation presentation facilities arc provided to allow the user to view and manipulate data as desired. In 
fact, different representations of the same data should be viewable with different formats, such as bar charts 
of data contained in columns of numbers. 

Ultimately, the executive mentioned above could evolve into an intelligent agent diat manages the user's 
distributed resources in much die same way a traditiotial command language inteipreter manages a single 
system's resources [78] . 'I'hcn and only then would die user be totally unaware of where die activities are 
actually being executed - local to the workstation, on remote hosts, or distributed dynamically between some 
combination of workstations and hosts. 



3.2.2 Reality 

ITiis diesis focuses on virtual terminal management issues, with particular emphasis on distributed graphics. 
The resulting workstation software will be referred to as the Virtual Graphics Terminal Service (VGTS). 
Below wc will consistently use Uie term virtual graphics terminal (VGT) in place of virtual terminal to 
distinguish it from more traditional work in network virtual terminals and window systems described in the 
previous chapter. The VGTS contains both a graphics package and a window system, as modules in the 
implementation to be described in Chapter 4. 

Although we have not solved all die problems of command interaction, simply in order to manipulate the 
screen wc have developed a reasonable command interface - for creating, destroying, and rearranging VGTs; 
managing executives: zooming, etc. In addition, many of die common command interaction techniques, such 
as menus and forms, require grapiiical support, wliicli the VG TS is can provide. In short, die VGTS provides 
the facilities necessary to experiment with a variety of different command interfaces. This disUnction between 
terminal management and command interfaces follows from previous work and is consistent with die recent 
trend towards user interface management systems [78, 143]. The rest of diis chapter describes die VG TS 
architecture in detail. 
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3.3 The Network Graphics Architecture 

The VGTS, as the rest of the V-System, fits the classic object or server model of software 
architecture [67, 155]: The world consists of a collection of resources accessible by clients and managed by 
servers. Wc will use the term client to refer to any entity (a human user or program) requesting access to a 
resource. We will use the tenn userio refer exclusively to humans. Architecturally, we make few assumptions 
as to how servers are implemented - as monitors or processes, for example. The current implementation is in 
the form of die message-based V-System, where servers are, in fact, processes. 

¥i)v the purpose of tenninal interaction, die principal resource is the workstation, tlie server is the VGTS, 
and clients consist of die user and application programs. Figure 3-3 presents the interrelationships among 
these components. Following die traditional virtual terminal model, applications communicate with die 
VGTS via die terminal-independent virtual graphics terminal protocol (VGTP), and with host software in 
whatever way necessary. The VGTS communicates with the hardware via die terminal-dependent real 
terminal protocol (RTP). Thus, the VGTS provides a protocol translation service between VGIP and R'l'P. 
Alternatively, the VGTP defines die interface or semantics of die VGTS. 
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Figure 3-3: High-level VGTS architecture 

In terms of the ISO Reference iVIodel for computer networking fl63|, the VGTP is a present<»don level 
protocol. Natuialiy, when used across a network, the VGTP must be encapsulated in appropriate session and 
transport pi otocols. We refer to the former as the network graphics protocol (HG\% described in Section 3.5. 

In terms of traditional graphics terminology, die VGTP is die graphics language and die VGTS implements 
die graphics package. Together, they offer similar functionality to a number of existing graphics systems, 
including those conforming to die ISO standard Graphical Kernel System (GKS)[64] and the proposed Core 
standai d [147] as discussed in chapter 2. The VGTP bears an even greater I'eseinblance to the proposed PlliGS 
standaid [4], which was developed at approximately die saine time. The R TP, on the odier hand, could easily 
be die pioposed ANSI Virtual Device Interface (Vl)l)[122] or the North American Presentation Level 
Protocol Syntax (NAPLPS) [6]. 
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3.4 The Virtual Graphics Terminal Protocol 

The VGTS has two very different protocol interfaces: one to the user and one to the client application 
program. First we will discuss in detail the protocol used between the VGTS and its clients, referred to as the 
VGTP in Figure 3-3. Instead of standardizing on a byte-stream or procedural interface, the VGTP was first 
specified as icinds of objects and a set of operations on those objects. I'his section describes diese abstract 
operations, and the next chapter discusses how the operations arc actually implemented. Figure 3-4 illustrates 
the relationships between the objects discussed in this section. The next chapter will contain a concrete 
example in Figure 4-2 to flirtlier explain these concepts. 
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Figure 3-4: Relationship of SDFs, VGTs, and Views 

The VGTS piovidcs two basic types of stiucturcs: structured display files (SOF) and virtual graphics 
terminals. E\c\y graphical object is defined within a specific SOF'; thus, an SDF represents an object 
definition space. In order to view an object, it is necessary, first, to associate the object's SDF definition with 
a VGT (by tlie program) and, second, to specify a mapping of die VGT to the screen (by tlic user). 



3.4.1 SDFs and their Manipulation 

An SDl ' consists of a collection of items. I'he items can be either primitives, or grouped into symbols, which 
can in turn be contained in ii>stiinces of other symbols, to any desired depth. The SDI^' forms a directed 
acyclic graph (DAG), with items as nodes of the DAG. Abstractly, symbol definition nodes have arcs to all 
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their component items. Symbol call nodes have arcs to the symbol definition node, and primitive items 
correspond to leaf nodes. 

An SDF is similar to a segment network in PiiiGS, while an item is equivalent to an element [4]. An SDF 
may also be thought of as a symbol system [56]. Items arc named by identifiers chosen by the application, are 
typed, and have type-dependent attributes. The ranges of tliese identifiers and attributes will be discussed in 
Section 4.3. Item types include: 

• line 

• (filled) rectangle 

• (filled) polygon 

• bitmap 

• text (in arbitrary fonts) 

• (filled) spline 

• symbol definition 

• symbol call 

All items are defined within a 2 dimensional integer world coordinate space. Translation is the only modeling 
transformation permitted on "called" symbols. All other transformations, such as rotation or projection from 
higher dimensions, arc presently handled by the application program. Attributes are specified as indices into 
type-specific attribute tables similar to the bundled attributes of GKS. However,, these attribute tables are 
shared by all VQTs and managed by tlie VGTS in its role as mediator between simultaneous applications. In 
contrast, GKS allows tlie single application to control tlie bundle tables. VGTS attributes are specified (at 
least indirectly) on each item, not inherited from calling symbols, as they are in PillGS, for example, or set by 
modes. 

A client can create and delete structured display files, symbols, or items. It may edit symbols, and obtain or 
change die properties of an item. The following functions are provided to manipulate the SDF: 

CreateSDFQ =>sdf 

Create a structured display file, and return its identifier in sdf. This must be done before any symbols 
are defined. 

DeleteSDF(sdj) 

Return all die items defined in die given s^^to free storage. 

DefineSymbol(sdf, item, name) 

Knter a symbol into die symbol table, and open it for editing. The sdf\& one returned from a previous 
CreateSDF call, item is an application-specific integer identifier for the symbol and name is an optional 
string name. 

EndSymbol (sdjC item, vgt) 

Close symbol item in sdf so no more items can be changed, and cause the vgt to be redrawn to reflect the 
new sdf. Called at the end of a list of items defining a symbol, started with CreateSynibol or 
liditSymboL 

EditSynibol (sdf item) 

Open existing symbol item in sdf for modification. This has the effect of calling DeJineSymbol and 
inserting all die already existing entries to the definitions list. The editing process is ended in the same 
way as the initial definition process: a call to EndSymboL 

DeleteSymbol (sdf item) 

Delete the definition of symbol item from sdf. Any dangling instances of tills symbol, created by 
AddCall, wilt remain, but will contain nothing. 
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AddCaU(sdf, item, offset, calledSymbol) 

Add an instance of calledSymbol to the currently open symbol in the sdf. The instcince is given the 
name item. The called symbol's origin will be placed at offset in the calling symbol's coordinate space; it 
is not windowed or transformed in any other way. This is equivalent to a move call unit in Sproull and 
niomas's structured format protocol [126], or an Execute call in NGS, as opposed to a Copy call. That 
is, changing the symbol definition changes all instances. This is more like a subroutine call tlian a macro 
expansion. 

Addltem (sdf item, extent, type, attributes, typeData) 

Add an item to the currently open symbol in tlie sdf giving it tlie name item, extent specifics the 
bounding box of tlic item in its coordinate space, type and attribute determine the type and attributes 
respectively. typeData contains any other data needed to define the item, such as the control points for 
a spline item or the text string for a text item. 

Deleteltem (sdf, item) _ 

Delete item from the currently open symbol definition in sdf. 

lnquireltem(sdf, item). => extent, type, attributes, typeData 
Return the parameters for item in sdf. 

inquireCall(sdf, item) => calledSymbol 

Return the item name, calledSymbol of the symbol called by the item in sdf 

Change ftem (sdf item, extent, type, attributes, typeData) 

Change the parameters of an already existing item in sdf This is equivalent to deleting an item and then 
reinserting it, so the item must be part of the open symbol 

3.4.2 VGT and View Management 

Once the VGTS client has defined some graphical objects, the client or the user needs to provide 
information on how the objects should appear. The VGTS lets a user see objects in any VGT anywhere on 
the screen in views. Each view has a zoom factor, a window on the world coordinates of the VGT, and screen 
coordinates which determine its viewport. Thus, a view defines a particular viewing transfonnation directly 
from world to device coordinate space. No intermediate transformations, such as normalized device 
coordinates, arc visible to the client. 

Although the client can create default views, the user can change tliem with the view manager, and create 
and destroy more of them, l^iich VGT can exist in zero or more views, but each view has exactly one VGT 
associated with it. Each VGT is associated with at most one SDF, but each SDF may be associated with 
several VGTs. Symbol definitions are shared between VGTs that have the same SDF. Thus one VGT can 
display at its top level a symbol that appears as a called instance at a lower level in some other symbol in 
another VGT. 

Functions for clients' manipulation of VGTs and views include: 

CreateVGT (type, name, sdf item) => vgt 

Create a VGT of type type and return its identifier in vgt. name is a client-specified symbolic name for 
the VGT that may be used later to select tliat VGT for input, item in sdf is placed as the top-level item 
in the VGT; it can be zero to indicate an initially blank VGT. The type can be some combination of 
Text, Graphics, and Zoomable. 

Destroy VGT (vgt) 

Destroy the given vgt and all the associated views. 
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DefauUView (vgl, width, height, wXmin, wYmin, zoom, showGrid) => width, height 

Create a view of the given display, with the user determining the position on the screen with the 
graphical input device, width and height give the initial size of the view; non-positive values indicate 
that the user should determine die size dynamically, in which case the selected values arc returned. 
wXmin and wYmin arc the world coordinates to map to the left bottom corner of the viewport; die 
amount of the world actually viewed depends on the size of the viewport and die zoom factor. The 
zoom factor is the power of two to multiply world coordinates to get screen coordinates; it may be 
negative, to denote that a view is zoomed out. Views are not otherwise transformed. If showGrid is set, 
a grid of points is displayed in the viewport. 

To display a new graphical object in a VGT after the VGT is created, either die old top symbol can be 
edited, or a new symbol can be defined and the following function called: 

Display Item (vgt, sdf, item) 

Change the top-level item in vgt to be item in sdf. The new item is displayed in every view of the VGT. 

DefaultView executes an implicit Displayltem after creating the view. EndSymbol may also cause output to 
appear after (re)defming a symbol, altiiough the VGTS redraws only the part of die view that has changed in 
this case. The VGTS implementation is also free to perform other optimizations, such as only drawing the 
additional items if the only changes before an EndSymbol are adding top-level primitives. Using Uiese 
functions, the VGTS client can achieve the effect of deferral modes for graphical output, including: 

batch ConstRict the graphical object in its entirety and then display it, by executing a 

DefineSymbol or EditSymbol, many Addltem calls, followed by an EndSymbol call. This 
corresponds to creating an invisible segment and making it visible, or using the At Some 
Time deferral mode in GKS. 

incremental Constmct and display the object "on the fly", that is, display each primitive item (each 
vector, for example) as it is added to the object, by repeatedly executing an EditSytnbol, 
Addltem, EndSymbol sequence. This corresponds to creating a visible segment, using the As 
Soon As Possible deferral mode in GKS. 

The latter approach may achieve better response, and is die normal mode of operation for most traditional 
graphics systems. However, as results will show, the former mcdiod usually achieves higher throughput, and 
is die norm for programs using the V.GTS. 

3.4.3 Input Event Management 

Since the VGTS was designed to support multiple simultaneous clients, it must decide which client receives 
which input events. 1'his is called input demultiplexing, and naturally occurs on a VGT basis. The following 
ftmctions are available for graphical input: 

GetEvent ( vgt. event Mask) => event Descriptor 

Wait for an input event to occur with respect to the iiidicated vgt and return a variant record in 
eventDescriptor Uiat describes the ev^nt. The record will contiiin die type of the event and tlie relevant 
type-dependent information. eveniMask specifies the acceptable types of input events: keyboard or 
mouse. The mouse events subsume button and locator devices of GKS, returning die buttons pressed 
and die location in virtual coordinates within the vgt. The first event in any of die indicated classes to 
occur is returned. 

FindSelectedObject (eventDescriptor, searchType) =>item, edgeSet 

Given an event descriptor as returned by GetEvent, return die item of die smallest object near the 
event, and a set of (Left, Right, Top, Bottom) edges which die event was near. 
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GetGmphicsStatus ( vgO => status 

Return tlie status of the graphical input device with respect to the indicated vgt including buttons 
pressed and location. As a side effect, the event queue is cleared of any outstanding graphical events. 

PopUp(menu) => selection 

Display a menu of choices at the cursor position, consisting of an array of strings, to the user. When the 
user selects a particular item, return the array index in selection. This is similar to the GKS choice 
device. 

GetEvent dLn6. GeiGmphicsStatus together provide the fiinctionality of tlie GKS input modes. The VGTS 
maintains an event queue for each VGT; all keyboard and mouse events related to that VGT arc queued in the 
same queue, in First- In-Fii'st-Out order. Thus the event mode of GKS is supported for both the keyboard 
and mouse tlirough GetEvent. Pick device functionality is obtained from the FindSelectedObject function, 
which is similar to request mode of GKS. GetGmphicsStatus allows the mouse to operate in sample mode. 
Sampling of the keyboard is not supported, since such a capability would be quite device dependent. 

Keyboard input is always associated with some VGT group. Each VGT belongs to exactly one group, and a 
group typically corresponds to an activity (although an activity can create multiple groups). Vhc groups are 
identified by their master, which receives keyboard input when the group is selected through the user 
interface. The next section describes the to il output interface, provided so the simple symmetric model of 
standard terminals can be used for echoing Keyboard input 

3.4.4 Text Terminal Emulation 

The VGTS supports a text VGT mode optimized for page-mode terminal emulation. Specifically, an 
application may treat a VGT as a standard ANSI terminal [1], such as a DEC VT-100. Such an application 
need not know anything about the graphical facilities of the VGTP, and may use the ANSI terminal protocol 
to communicate with the VG1'S, including escape sequences for cursor control. Output to the VGT is stored 
in a pad]Jl\ which is a symbol within an SDF. The symbol consists of a linear array of simple text items, 
each of v/hich represents one line. 

Note tliat the terminal emulation output interface is of a different nature from (and therefore, 
unfortunately, incompatible with) the graphics interface as discussed above. However, this does not prevent a 
mixed text and graphics application. One particular type of graphics item is text, permitting a client to easily 
integrate text and graphics within a graphics VG F. The terminal emulator interface is provided to optimize 
performance for a typical special case. 

The VGTS architecture provides several advanced features for the support of keyboard input processing. 
Applications can operate in "raw" mode, or selectively enable any of the following features: 

Local Fx:h() This allows instant response to keyboard input, providing useful feedback to users of 
potentially loaded timesharing systems. 

Line Editing Programs that interact on a line-by-line basis, such as the executive, can cause lines to be 
buffered (and usually echoed) inside the VGTS. Sophisticated editing commands arc 
available on the line buffer, and the executive (for example) can "stuff previous command 
lines into the line buffer, in conjunction with its history mechanism. 

Paged Output When this mode is in effect, the VG TS will block output requests larger than one page. A 
message is displayed in the banner, and the user types a command to unblock when ready. 

Graphics Escapes Inside a pad, when connected to some remote hosts tlirough a Tflni: r program, graphical 
input events can send escape sequences back to tlie application. This allows many useful 



36 



PARTITIONING OF FUNCTION IN A DISTRIBUTED GRAPHICS SYJlTiM 



programs that deal with conventional terminals to be simply extended to take advantage of 
graphical input capability without major redesigns of the applications. For example, an 
Emacs[129] library can be loaded to bind these character strings to commands that 
position the text cursor, set the Emacs mark, delete and insert text. 

By default, keyboard input is line-buffered and echoed by tlie VGTS; with the powerful line-editor built in. 
Support for text editing by a pointing device could be provided, transparently to applications. This has been 
partially implemented in one user's custom version of the VGTS. 



3.5 The VGTS Client Protocols 

The VG'I'P is constant over all applications, but allows for a wide variety of bindings to lower-level 
protocols. Some applications have no knowledge of the VGTP and some applications are iimning on 
machines that do not support the interprocess communication mechanisms underlying the VGTP. Whenever 
the application is running remotely, the VGTP must be encapsulated within an appropriate network transport 
protocol. The following situations arise (see Figure 3-5, in which each inter-machine arc is labeled with an 
example (presentation protocol, transport protocol) pair): 
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Figure 3-5: Possible clients of the VGTS 

• Application A runs on the workstation and communicates via V kernel messages. Current 
examples include text editors, document illustrators, and design aids. 

• Application B and the VGTS run on two separate machines that support network-transparent 
interprocess communication, such as tlie V-Systcm inter-kernel protocol {\KP), 7i communicates 
with the VGTS via the VGTP, as in the case of a application A. 
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• Application C runs on a machine that does not support network-transparent IPC, but does 
support a traditional network architecture. In addition, a VGTP interface package is available that 
encapsulates the VGTP within tlie appropriate transport protocol. Similarly, a local agent for the 
application, C*, is created on the workstation to decapsulate the VGTP. Thus, the application may 
still be written in terms of the VG TP and neither it nor the VGTS have any knowledge that the 
other is remote. Our VLSI layout editor, for example, can be run in tliis fashion under 
Vax/Unix. 

• Application D has no knowledge of the VGTS or the VGTP; it wishes to regard tlic workstation as 
just another terminal. The local agent, D\ is "user TELNET" and perfomis the appropriate 
U anslations between Telnef and VGTP. 

• Application E is distributed between the workstation and one or more other machines. The local 

agent, E*, is responsible for communicating between the distributed parts of tlie application and 
the VGTS. It must perform the appropriate set of protocol conversions indicated above. In 
addition, it may wish to perform application-specific flinctions, such as high-level caching. In that 
case, the protocol used to communicate with the remote applications may require more than 
simple transport service. 

All applications but A use a network transport protocol, whether they realize it or not. Application B 
employs an interprocess communication protocol that has nothing to do with graphics per se. Application D 
employs a protocol that in no way depends on knowledge of tlie VGTS and typically has nothing to do with 
graphics: in order to run, an appropriate protocol-converter must am on the workstation. 

Applications Cand £, on tiie other hand, know all about the VGTS and are ver>' interested in graphics. We 
will refer to the protocol tliey employ as the network graphics protocol (NGP). The NGP may be a simple 
encapsulation of tlie VGTP by an existing transport protocol, it may be a problem-oriented protocol [117], or 
it may itself be a multi-level protocol. Application C, for example, may find a direct encapsulation of the 
VGTP acceptable. Application E, however, may wish to maintain a replicated database (the main database 
plus the cache), or may wish to trade reliability against cost. In these cases, the NGP offers considerably more 
functionality than mere encapsulation/decapsulation of the VGTP. In general, the VGTP and NGP 
correspond roughly to presentation and session layer protocols, respectively, in the ISO reference model [163]. 
The transport protocols used in the prototype implementation arc discussed in Section 4.3.5. 

3.6 Summary and Implications of the Architecture 

This chapter presented a high-level virtual graphics terminal protocol that is the key element of the VGTS 
architecture. This protocol is used by applications to specify graphical objects with hierarchical structure. 
The use of standard protocols helps to provide device independence. Any application program which uses 
the standard protocol can be used with any implementation of the VGTS, without any modifications. More 
information about how this is achieved, and other details of the prototype implementation arc given in the 
next chapter. Chapter 5 discusses the rationale behind tlie design of both the architecture and the 
implementation, including why the design facilitates distribution and concurrency. As will be shown in the 
Chapter 6, this protocol is successful in limiting both the frequency of conununication between application 
and VGTS and the amount of data transmitted at any one time. 
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— 4 — 

An Implementation of the VGTS 

The architecture described in the previous chapter is independent of any implementation. Programs 
developed for one implementation of tlic VGTS should be able to run with any other implementation, given 
the existence of the appropriate transport protocols. In this chapter we will first describe the organization of 
one particular prototype implementation. This implementation actually adapts itself at run-time to several 
different varieties of workstations, and many modules can be used on other very different workstations. The 
techniques used in this implementation to update the screen arc discussed, followed by the client interface, 
and dien the user interface. Finally, an example application program is described: a simple illustration 
editor. 



4.1 General Organization 

As noted in Section 3.2, the VGTS is only one component of the user interface software in the V-System. 
The other components are: 

• the view manager 

• the exec server 

• the executives 

• the application library 

ThQ view manager provides the means by which users can create, destroy, and modify the screen layout, as 
well as create new executives. Kxecutives represent instances of the same basic command interpreter, as 
defined by tlie exec server. To create a new executive, the user communicates mih the view manager, which 
communicates with tlie exec server. The user may replace the exec server at any time, effectively redefining 
the executive command inteipreters. Logically, the view manager is another module that may be replaced. 
Ultimately, however, these components employ tlie services of the VGTS to communicate with the user. 

In fact, the VGTS is merely an instance of a terminal agent. Hence, the user may also replace the VGTS at 
any time with simpler terminal agents, or other window systems. This facility permits a programmer to 
develop new graphics facilities without having to constantly reboot his workstation. On tlie other hand, it 
provides the mechanism by which the same user interface management system can communicate witli a 
substantially "reduced" terminal agent such as the simple terminal server (STS), a subset of tlic VGTS 
architecture which runs on a simple text-only terminal [17]. 

4.1.1 VGTS Implementation Modules 

At one more level of detail, each terminal agent is composed of multiple components. In particular, tlie 
VGTS implementation consists of the following modules: 

master multiplexor Handles all client requests by dispatching to the appropriate routine in other modules. 

Provides synchronization between all the possible clients, by receiving messages from 
them. The major part of the operating system interface is contained in Uiis module. 

escape interpreter Monitors the incoming byte stream for graphics commands and calls die SDF 
manager to perform tliem. Other characters are passed tlirough to the terminal 
emulator. 

terminal emulator Interprets a byte stream as if it were an ANSI standard terminal [1], Printable 
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Figure 4-1: Process and module structure of tlie VGTS 

characters arc added to text objects, and control and escape codes are mapped into the 
proper VGTP operations. 

Handles requests to create, destroy, and inodify graphical objects within structured 
display files. Maximum extents of symbols arc maintained to help the redrawing 
process. This is elTectively the display file conipilcr[21, 56]. Included is a luish tiiblc 
manager to keep track of symbol definitions and item numbers. 

Highest-level graphical output operations. The structured display file is visited 
recursively, with appropriate clipping for extents totally outside the area being drawn. 
This is effectively the display processing unit. In a higher-performance 
implementation this module and the ones below it could be implemented in hardware. 

The structured display file is visited, but instead of actually drawing the primitives, the 
positions arc checked to match the cursor's position. A list of possibly selected objects 
(under other optional constraints) is returned to tlie client. 
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Handles the event queues, line buffering, and the blocking and unblocking of clients 
waiting on events. 

Provides the user interface for screen management. Although this is logically a fairly 
separate entity from the lower-level functions of the VGTS, in the current 
implementation it is provided as a module which runs as a coroutine to tlie master 
multiplexor process. 

Perform the view-changing operations. These are the operations invoked by the view 
manager, such as creating, deleting, and modifying views. 

Low-level but possibly device-independent operations, such as handling tlie 
overlapping viewports. AJthough this module docs not do any frame buffer 
operations directly, it uses several device-dependent parameters, such as the size of die 
screen in physical coordinates. Also, some of these operations could be done in 
hardware on higher-performance graphics devices. 

Device-dependent graphics primitives called by the display manager. On the SUN 
workstation, for example, these primitives manipulate tiic frame buffer. On other 
lower-performance workstiitions this might be done by a separate process to prevent 
the multiplexor process from blocking for long periods of time. 

Device-dependent modules for reading the keyboard and tracking the mouse. There 
is also a timer module to supply periodic messages to the multiplexor. 



The relationships between these modules are illustrated in Figure 4-1. ITie general direction of control is 
indicated by the direction of the arrows. The higher level modules near the top of the figure call lower level 
modules near the bottom. 



4.1 .2 Team and Process Structure 

The V-System provided three techniques for structuring software: modules, processes, and teams. 
Modules are groups of functions that communicate Uirough function calls and global variables. The kernel 
manages independent concurrent prtxiesses, which communicate Uirough messages or shared memory. Only 
processes on tlie same team share memory; separate teams arc separate virtual address spaces. The process 
structure of the VGTS is also illustrated in Figure 4-1, by the presence of the thick arrows. The arrows are 
drawn in tlie direction Uiat messages are sent, from die sender to tiie receiver. The VGTS implementation 
consists of four processes: 

1. ITie keyboard helper process reads from the kernel console device and sends messages to the 
master multiplexor. 

2. The mouse lielper reiids from the kernel mouse device and sends messages to the master 
multiplexor. 

3. 'ITic tinker helper delays for a set period and sends timing messages to tiie master multiplexor. 
Several activities are triggered by Uiese messages, including a blanking of the screen after ten 
minutes if no other messages have been received. 

4. The master multiplexor process synchronizes all frame buffer operations, and performs most of 
the other functions. 

The low level interface to the console, mouse, and timer is implemented by the V kernel Normal messages 
are sent to a pseudo-process called the "device server" which will block until data is available. This blocking 
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necessitates the three extra helper processes for these devices. The main loop of the VGTS, like most servers 
in the V-System, consists of a Receive primitive followed by a switch on the type of request. The main 
process of the VGTS should never block for significant periods of time. 

4.1 .3 ModuleSizes 

The number of lines of source and the number of bytes for object code for each of the modules is given in 
Table 4-1. The "Others" line refers to lines of code in the header files, and bytes obtained from libraries. 
Note that about one third of the object code is obtained from libraries. Another interesting observation on 
tile relative sizes of modules is Uiat tiie module tiiat is largest in source and second largest in object code 
(spline and polygon flmcUons) is very rarely used. 



Module 


Source Size 
(l.incs) 


Object Size 
(Bvtes) 


Display 


442 


3475 


Splines and Polygons 


1498 


10068 


SUN Drawing Manager 


1423 


8860 


Event Handler 


1150 


6540 


SDF Interpreter 


638 


6540 


Escape Interpreter 


594 


5164 


Input Handlers 


427 


2416 


View Manager 


1137 


9920 


Hit Detection 


983 


6024 


Master Multiplexor 


1045 


8212 


Terminal Emulator 


896 


6000 


SDF Manager 


1349 


14240 


View Primitives 


1209 


8676 


Others 


425 


51059 


Total 


13283 


140654 



Table 4-1: VGTS implementation module sizes 



4.1 .4 Adaptive Techniques 

The VGT'S uses several techniques to adapt to its environment. First, several link-time versions arc 
available. In die full configuration, the basic V-System services (such as tiic exec server, context prefix server, 
team server, exception server, etc.), are provided by one team, which loads another team at initialization 
consisting of tiie VGTS and a default view manager. The user can then issue a command to replace die entire 
VG rs and view manager at run-time. Since this capability is rarely used except by some VG TS developers, 
another con figuration has the VGTS linked together with the basic services into a single teum. 'I'he two-team 
version Uikcs longer to load, and occupies at least 50K bylcs more of memory and another team descriptor. 
Mnally, for systems that are short of memory, a reduced function VGTS is available with no splines, polygons, 
or font loading facilities. 

The low-level VGTS device driver has to deal with subtie differences among the many vereions of SUN 
workstation hardware that have evolved over the years. Some differences arc handled by tiie V kernel device 
server, which provides virtual keyboard and mouse devices. Other parameters, such as the exact screen size 
(which varies from 796 lines by 1024 pixels to 1024 lines by 800 pixels) and die virtual address of tiie frame 
buffer, are determined at run-time with the aid of a kernel workstation query operation. 

More changes were required to support an implementation of the VGTS for a later model of the SUN 
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workstation, called tlie SUN-2. Initially the single installed VGTS would query the kernel on start-up to 

determine tlie type of frame buffer and set a variable. Tliis variable was tested before each primitive to 
determine which low-level graphics function to call. Altliough the run-time CPU overhead was acceptable, 
the memory usage of the combined version eventually prompted the split into separate versions for the 
SUN-1 and SUN-2 frame buffei*s. Interestingly, the mere act of identifying device dependencies tliat had 
crept into modules that were previously thought to be device dependent, resulted in cleaning up die 
implementation and marginally decreased the size of the original SUN-1 implementation. 

Additional techniques could be used for adaptation in fliture implementations of the VGTS. For example, 
if the V.-System implemented virtual memory then the rarely-used modules could be page-faulted into 
physical memory only when actually needed. Dynamic linking could also be used to reduce the minimum 
memory requirements, at the expense of slightly more complicated inter-module linkages. Dynamic linking 
would also require more complicated debugging tools, and possibly introduce reliability problems. 

4.2 Screen Updating 

This section discusses the techniques used for displaying objects, the end result of VGTS operations. In 
contrast to many systems, tlic VGTS provides centralized rather Uian distributed control of screen updating. 
The next chapter, and in particular Section 5.4, will discuss the rationale behind this decision in greater detail. 
There are a fixed set of graphical primitives, executed under tlie control of the VGTS SDF interpreter, display 
manager, and drawing manager, the lowest level modules in Figure 4-1. This centralized control eliminates 
any possibility of applications interfering with each other. In fact, operations on the SUN frame buffer 
cannot be interrupted and restarted, so, some kind of synchronization is necessary. Moreover, centralized 
control is the only reasonable approach for distributed applications. The user methods of object oriented 
window systems discussed in Chapter 2 rely on shared memory, which is not typically available in a 
distributed environment 



4.2.1 Implementing Overlapping Viewports 

Originally, viewports were restricted to lie entirely on the screen and to not overlap. However, this proved 
to be Inadequate, since screen space quickly filled up, and viewport manipulation commands often failed. 
ITie current implementation uses a novel scheme of dividing each viewport into visible non-overlapping 
rectangles (called subviewports) whenever the screen layout changes. The viewports arc redrawn by 
interpreting the stmctured display file in each of the subviewports. This has the advantiige of no speed 
penalty for updating views that are not obscured (the normal case). Views which have non-rectangular visible 
portions may take longer to update for complicated SDFs, but almost always Uie actual drawing time is tlic 
dominating factor, which is proportional to the area being redrawn and independent of the shape of tlic 
region. The resulting scheme is clean and simple. 

One major advantage over systems thnt maintain obscured bitmaps (such as Apollo Domain [8], Blit 
I -ayers [105], and Spice Canvas [1 3j) is that no extra memory is required to store those obscured bitmaps. The 
S\W can represent extremely large objects in modest amounts of memory. As an example, consider the two 
overlapping viewports in F'igure 4-2. The SDF data structures take up only a few hundred bytes, while die 
bitmap could need many thousands of bytes. View number 1 lies on top, and is entirely on die screen, so it 
has only one subviewport, number 1. View number 2 is partially obscured, so it has two rectangular 
subviewports, numbers 2 and 3. The "banners" or labels on the top of each view are implemented as 
additional subviewports, each displaying a single item: a string name, VGT number, optional view number 
and zoom factor, and a string controlled by tlie application. 

Another advantage of updating from die SDF instead of from a bitmap, is diat it is often actually faster to 
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Item 2: Line (frame) 



Item 4: Symbol, "Wheel" 



Item 0: Circle 
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vgt 1 view 1 
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(subviewport 3) 



VGT 1 



Top Symbol: 1 
Name: "Bike Editor" 

Views 



View 1 

viewport 
Depth 
Window 
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Depth 
Window 
Subviewports 



Figure 4-2: Example of item naming 

redraw the picture from tlie SDI^^ tlian to restore tlie bitmap, assuming tliat the bottleneclc of graphics is tlic 
frame buffer update bandwidth. For example, a picture composed of vectors usually has a low density of 
pixels touched by the vectors. For scrolling text, our experience has been that it is significantly faster to 
redraw a single character on the SUN-1 than it is to scroll it by moving the bitmap. 'I'his is because moving 
ihe bitmap touciics each bit of the frame buffer twice (one read and one write), wliiie redrawing touches it 
only oticc. The source for the redrawn character is main CPU inemory, whicli is accessed more quickly tlian 
frame buffer memory. Unfortunately, the SUN-2 frame buffer was designed to optimize large raster 
operations used in the raster-oriented software marketed by SUN ivlicrosystems, instead of the many small 
operations done by the VG TS. In other words, on tlie SUN-1 frame buffer the bottleneck was the number of 
bits per second tliat could be sent over the I/O bus, while on the SUN-2 the bottleneck is tlic number of raster 
operations per second. The result is that tlic SUN-2 frame buffer is slower than the SUN-1 for all VGTS 
drawing operations. 
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4.2.2 Zooming and Expansion 

The VGTS provides support for zooming and expansion depth that is independent of its clients. Zooming 
consists of redrawing the SIDF with larger objects, not replicating pixels. Expansion deptli, one of the 
attributes of each view, indicates how far down in the SDF to go when displaying a symbol. If the expansion 
depth is less than the SDF tree height, an outlined box will be displayed at the appropriate point in place of 
the symbol. Depending on the size of the box, the text name of the symbol may also be displayed. Views may 
be zoomed and expanded independently such that a user may view an entire symbol in one view, for example, 
while simultaneously viewing a piece of the symbol in a zoomed-in view. 

4.3 Client Interface 

Before the techniques described in the last section can be used to display objects, the objects must be 
defined by some client application program. The abstract objects and operations were discussed in the 
previous chapter. Section 3.4. The details of tlie C language binding for tliis interface are discussed in the 
V-System Reference Manual, in tlic chapter on the graphics library functions [17]. This section discusses 
some important design choices taken in tlie prototype VGTS implementation regarding the client interface. 

4.3.1 Item Naming 

Items within an SDF are named with 16 bit identifiers chosen by the application. It is assumed that the 
application will maintain some higher-level data structures, along with the appropriate mapping to these 
internal item names. The item names are global to each SDF, but applications may also have several SDFs 
for different name spaces. Item idendfiers are referenced via a hash table, so tliere are no constraints on their 
values [73]. Items that will never be referenced can be given item number zero, and are never introduced into 
the hash table. In practice, only a few "interesting" items are actually given non-zero numbers. Item 
numbers can refer to both definitions of symbols and their instances. Symbols are also given string names, 
but tliesc strings are only used for disambiguation during hit testing, or for displaying symbols at the 
expansion depth. String names of symbols are not related to item numbers. 

For example, a.picture of a bicycle might define a symbol for a wheel. The item number of the top-level 
"bike" symbol could be 1, with 2 and 3 referring to other parts of the symbol. 'I'he definition of the wheel 
symbol is given item number 4-. There may then be two instances (calls) of item number 4, which could be 
given item numbers 5 and 6. The individual spokes of the wheel are components of symbol number 4, but are 
all given item number 0, since we will never want to refer to any of them individually. If it is desired to delete 
or move any individual spoke, then each of these items may also be given numbers. Figure 4-2 on page 44 
illustrates tiiis example. 

4.3.2 Representing SDF Items 

Section 3.4 introduced some of the kinds of item types used in tlie VGTS. The implementation uses a 
compact linked list of display records to represent these items internally. Bach item within an SDF has the 
following parameters: 

Item A 16 bit unique (within the SDF) identifier for this object, or zero. This identifier is 
referenced by the client when performing editing operations. 

Type One of the predefined types described below; either a primitive type or one to indicate 
structure. Cui renUy eight bits arc allocated to this. 
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TypcData Eight bits of type-dependent information, such as the stipple pattern index for a filled 
rectangle. Most attributes are stored here, such as the font index for general text 

Xmin Minimum X coordinate of the extent. All coordinates are in "world" coordinates, stored as 
signed 16 bit signed integers. 

Xmax Maximum X coordinate of the extent. 

Ymin Minimum Y coordinate of tlic extent. 

Ymax . Maximum Y coordinate of the extent. 

Pointer Depending on the type, this is cither a pointer to some data such as an ASCII text string, or 
for symbol calls, a pointer to the called symbol. 

Sibling All the component items within a symbol are linked together via this chain. This is a 
circular chain, as illustrated in Figure 4-2. Normally tliis relationship should not be visible 
to the client, unless the client wants to step through a symbol definition in order. 

Some of the meanings of the above fields depend on the type of the item. The following are tlie types of 
items that occur in structured display file records in the prototype implementation: 

Filled Rectangle A rectangle filled with some texture. The TypeData field specifies the stipple pattern, or 
color on tlie Iris system. 

Horizontal Line Horizontal line from (Xmin, Ymin) to (Xmax,Ymin). Ymax is ignored. 

Vertical Line Vertical line from (Xmin,Ymin) to (Xmin,Ymax). Xrnax is ignored. 

A point, which usually appears as a 2 by 2 pixel square at (Xmin.Ymin). 



Point 
Simple Text 



General Line 



Outline 



Text 



Raster 



Spline 

Filled Polygon 



A simple text string, with (Xmin,Ymin) as its lower left corner. This produces text in a 
single fixed-width font that can be drawn very quickly. The values of Xmax and Ymax 
need not surround tlie text, but they are used as aids for redrawing, so should correspond 
roughly to the real extent. 

A generalized line, from (Xmin,Ymin) to (Xmax,Ymax). Note tliat Xmin etc. are slightly 
misleading names. The SDK manager actually sorts the endpoints and calculates the extent 
correctly. 

Outline for a selected symbol. Xmin, Xmax, Ymin and Ymax give the box for the outline. 
The TypcData field specifies bits to select each of the edges: LeftKdge, RightEdgc, 
Top Edge or Bottom Edge. 

A string of general text, with a lower left corner at (Xniin,Ymin). The TypcData field 
specifics tlie font number. Xmax is recalculated from the widtli information for the font. 

A general raster bitmap with a lower left corner at (Xmin, Ymin), and upper right corner at 
(Xmax, Ymax). The TypeData field determines if die raster is written witli ones is black or 
white. 1'hc pointer field points to tlie actual bitmap, in 16 bit-wide swaths. 

A spline object, optionally filled with a specified pattern. The pointer field points to a 
SPLINE structure. 

A list of points which defines a polygon that can be optionally filled with a specified 
pattern. 
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Arcs / A list of points defining a scries of circular arcs. Although arcs can be very closely 

approximated by splines, this provides a simpler interface and faster implementation. 

There are a few other types that are not visible to the user. For example, symbol definitions and calls are 
represented as items with most of the same attributes. 

4.3.3 Interface to V-System Protocols 

The VGTS implements a subset of the standard V I/O protocol [33]. llius simple applications can write to 
standard output and read from standard input, with no changes required when executing under the VGTS, 
under the simple terminal server, or with input or output redirected to any other file. Pads are created by the 
standard request to create a file instance, and destroyed by the standard request to release a file instance. 

The VGTS also implements some of the operations in the V distributed naming protocol [34]. When die 

standard directory listing program is used to list the directory of the context named vgts, information about 
the currently defined virtual terminals will be printed. Thus each virtual terminal is a named V I/O object. 

4.3.4 Binding the VGTP to a Byte Stream 

The fimctions described in section 3.4 arc all encapsulated in escape sequences to form a byte stream using 
a very simple protocol. Each call causes a special flag character to be sent (tlie Ascii character called US, octal 
037) followed by a one-byte code indicating die function number. This is followed by each of the arguments 
to tlie function, transmitted with the high-order byte first in each argument. Any return values are sent with 
the same escape character followed by the bytes of tlie returned value, high-order byte first. Most parameters 
are sixteen bit unsigned integers, requiring two bytes for each value. 

This results in a very small number of bytes for common operations. As we shall see in the next chapter, 
this makes the protocol fairly insensitive to network speeds. A more ambitious project would have used an 
automatic "remote procedure call" generator [102], but tlie manual method was sufficient for Uiis project, 
since die functional interface did not change very often. An automatic RPC mechanism should not affect the 
performance of applications, and in fact should be entirely transparent. 

4.3.5 Network Transport Protocols 

The encapsulation of the VGTP within transport protocols is illustrated in Figure 4-3. Dashed lines 
separate library packages, solid lines separate programs, and arrows indicate network protocols. All 
interaction to tlic VG TS is through the V Input/Output protocol (VIO), which provides a byte stream of data 
in terms of V messages. The i n terp module decodes graphical operations out of tills byte stream, providing 
die server side of the remote procedure call facility. The terminal einulator Is also provided as a simple VIO 
byte stream interface. Clients use cither the VIO stream package, or the Unix Stdio package. The stubs 
module encodes graphical inibrmation on the standard output channel and decodes responses Irom st^nidard 
input 

For distributed applications, one of three network transport protocols can be used^: 
1. PUP Ti'LNEr [19] 



^Rolh TRLNirr prolocots arc used as "transport" by remote VGTS clients, even though they arc usually treated as presentation-level in 
the ISO hierarchy. Ihe distinction is in name only. 
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Figure 4-3: Encapsulation of the Virtual Graphics Terminal Protocol 

2. Internet Telnei' [107] 

3. V-System Inter- Kernel Protocol [31] 

These are standard, general-purpose transport protocols, with nothing specific in their design foi distributed 
graphics. In particular, the Internet Protocol allows use of any of the hundreds of computing resources on the 
Arpa Internet with no iTiodifications to their operating systems. 

4.4 The View Manager Interface 

The view manager provides the visible interface between a person using the V-System and the VGTS. lliis 
is very different from the programmer's interface to the VGTS which was described abstractly in Section 3.4, 
and discussed in the previous section. Programs create SDKs and objects within tliem, and associate these 
objects with Virtual Graphics Terminals (VG I s). Through the view manager, the user maps these VGTs onto 
a physical screen, and manipulates the resulting views. The view manager also provides the ability to manage 
executives, through an interface to the exec server. A siniilar componenl in other systems is usually called the 
window manager or screen manager. This section describes the .default view manager in tlie prototype VGTS 
implemcnttition. 



4.4.1 VGTS Conventions 

On tlie physical screen, virtual terminals appear as white overlapping rectangles with a black border and a 
label near the top edge called the banner. There is at most one virtual terminal (usually a pad, or text-only 
virtual terminal) tliat is receiving input from the keyboard, along with possibly other virtual graphics 
terminals receiving graphical input. These input selections are indicated by a flashing box (the text cursor) in 
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the text virtual terminal, and a black label on all the views that arc accepting input. Note that all virtual 
terminals arc always active in the sense that any application may run or change tlic display in any virtual 
terminal at any time independent of these selections; selections only apply to input. 

There arc a few conventions for using the mouse with the VGTS. A click consists of pressing any number 
of buttons down and releasing them at a certain point on tlic screen. While the buttons are down there may 
be some kind of feedback: usually an object that follows tlie cursor. The click is usually only acted upon 
when all the buttons are released, so if users decide they have made a mistake after pressing the buttons they 
can slide tlie mouse to some harmless position before releasing the buttons. Holding all three buttons down is 
also interpreted as a univereal abort by most programs and the view manager. The click event is sent to the 
program associated with the view in which the event occurred (through its VGT). 

Clicking the left or middle button of tlic mouse in a non-selected virtual terminal will cause it to be selected 
for input. Views of selected pads will be brought to the top. The input pad can be changed by typing the 
control up-arrow character (octal 036) followed by a single command character. The only command 
characters interpreted by the VGTS are 1-9 to select the given pad for input. 

Although the user can always create views, some are created by application programs. In particular, 
programs like tlie text editor will create a pad when a new virtual text terminal (pad) is desired. When a 
V-System program requests the creation of a pad, the cursor will change to tlie word "Pad". At this point, the 
user holds down any button, and an outline of the view that will be created will be tracked on the screen. The 
user positions the view where desired, and releases tlie buttons. Other prompts can appear as cursor changes 
to denote that the next click will not be treated as normal input. Unfortunately such convenience features 
make the view manager very device-dependent 

4.4.2 View ManagerMenus 

The view manager menus can always be invoked by moving the cursor to the grey background area or any 
virtual terminal not selected for input (except in tlie banner area) and pressing the right button. '^Thc 
following commands are available from the view manager menus: 

Create V iew Creates another view of an existing VGT. Move the cursor to the desired position of any 
one of tlie four corners for the new viewport. Mold any button down, and move Uie cursor 
to the diagonally opposite corner. An outline of the new view will follow the cursor as it 
moves with the button down. Let the button up, and then point at the VGT that is desired 
to be viewed with the left or middle buttons, or hit the right button and select the VGT 
from the menu. Nomially tliis command is only used with graphics VGTs. 

Delete View One view is clicked and removed from the screen. If the last view of a VGT is deleted, it 
does not destroy the VG T or die process associated with it. It is still possible to create 
views of the VGT by using the right button menu in tlie Create View command. 

Move Viewport Pressing any button selects a viewport to move. While the buUon is being held down, the 
outline Of the viewport will move, following the cursor. The button is released at the 
desired position. None of the ether view parameters are changed. A shortcut to tliis 
function is obtained by pressing tlie middle button while pointing to the banner of the 
desired viewport. The viewport outline will follow tlic cursor until tlie middle button is 
released. 



Make Top 



Brings the view to the top, potentially obscuring other views. A shortcut to this function is 
obtained by pressing the left button while pointing to die banner of die desired viewport. 
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Make Bottom Pushes the view to tlic bottom, potentially making otlicr views visible. A shortcut to this 
function is obtained by pressing the right button while pointing to the banner of the view. 

Exec Control Selects a submenu to create another executive, destroy an executive (and the teams nmning 
in it), kill a program, or control paged output mode. When creating an executive, the 
outline of the new pad will follow the cursor as the user holds the button down. The user 
lifts tlie button up at the desired position, or presses all Uiree buttons to abort. A shortcut 
to the exec control menu is obtained by pressing both die middle and right buttons while 
the cursor points to the gray background or the display area of a viewport not selected for 
input. 

Graphics Commands 

Selects another menu of commands tliat are usually only applied to graphics views. A 
shortcut to this menu is available by clicking tlie right and left buttons at the same time 
while die cursor points to the gray background or the display area of a viewport not 
selected for input. These graphics commands are described below: 

Center Window Click the position to become the center of the viewport. 'ITiis command does not change 
the position of die viewport on die screen, just the objects within the view. Normally this 
command is applied only to graphics views. 

Move Edges Push any button down next to an edge or corner, move that edge or corner to die new 
position, and let the button up. The edge oudine should follow the cursor as long as die 
button is held down. Does not move the objects being viewed reladve to die screen. 

Move Edges + Object 

Similar to the previous command, but this one drags die underlying objects around with 
the moved edge or corner, while the previous command keeps it stationary with respect to 
the screen. 

Zoom Invokes a zoom mode, indicated by a change in die cursor to the word "Zoom". Users can 

get out of this mode in two different ways: First, clicking the left or middle buttons when 
the cursor is inside a view of a pad returns from the view manager and selects that pad for 
input. As a side effect diat view is also brought to the top. Second, users can click the right 
mouse button to exit this mode. The cursor should change back to die normal arrow. 

The left and middle buttons in zoom mode zoom out and in respectively. That is, the left 
button makes die objects look smaller, and the middle button makes diem look larger. A 
shortcut to this mode is available by clicking the middle and left buttons at the same Ume 
while the cursor points to die gray background or the display area of a viewport not 
selected for input 

Expansion Depth Click to determine the view, dien select die new expansion depth from die menu. Symbols 
will not be expanded more dian diis many levels into the hierarchy. Instead they will be 
drawn as outlines with text for their names if diere is room. The default expansion depth is 
infinity, so all levels will be normally expanded. 

Redraw Redraws all the views on the screen; necessary only during debugging. 

Toggle Grid Click once to turn the grid on if it is off, or off it is on in die view selected. ITie grid dots 
are every 16 screen pixels, and always line up with the origin. 

Debug Enables extra printouts, for maintenance use only. This command asks for confirmation, 

to discourage its accidental invocation. 
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4.5 A Simple Application 

The VGTS and View Manager provide many fimctions that encourage appHcations to be simple and 
consistent. The s il edi t program, a simple illustration editor, is an example VGTS client program. It uses a 
compatible file format with tlie Alto SIL program, although some advanced features such as macros are not 
implemented [141]. The main limitation of this format is that only horizontal and vertical lines are supported, 
with a limited range of fonts. On the other hand, it is simpler and faster than the other V-Systcm illustrator 
(draw), and illustrations produced by si 1 edi t can be easily printed or inserted into other documents. A 
remote version of tliis program executes under Unix, although users prefer the V-System version when 
permitted by workstation memory limitations. 



4.5.1 Basic Operation 

The s i 1 e d i t program is invoked witii one argument in tlie V-System executive: 
si 1 edit filename. sil 

It first attempts to open the file name given as an argument. If no such file exists, the program creates one. A 

graphics VGT is created, and the cursor changes to the "View" prompt indicating the creation of a default 
view. The default view will be slightly larger than the illustration, or a whole page if the illustration is empty. 
The user presses and holds any button causing an outline of the new view to appear and track the cureor. The 
user moves the upper left; corner of the default view, and lifts the button up when the view is positioned. 
Next the si 1 edi t program prints the names of the text fonts to be used, and tiles to load them into the 
VGTS. The existing illustration is displayed (along with some performance statistics), and the following 
prompt appears: 

Use mouse buttons: Mark, Select, Menu 
This means two mouse buttons are used for the basic commands, with other commands available through 
combinat ions of buttons or from the command menu. 

The mark, indicated by an "X" shaped cross, is one end of lines and the position of added text. Once added 
to the illustration, objects can be modified by selecting them and performing a modification command. 
Selected objects appear highlighted in some way, although the exact fonn of die highlight may depend on the 
VG I S implementation. In the SUN implementation, objects are nonnally black on white, with selected lines 
half-tone gray and selected text appearing within a gray box. 

4.5.2 Commands 

Commands available on die mouse are as follows: 

Left Button Moves the mark to the point of the click. The "X" shaped cross moves to die new location. 
The mark is normally moved before drawing lines or placing text. 

Middle liutton Selects the single object at or near the click. Any other objects previously selected are no 
longer selected. The program will echo Uic kind of object selected, or issue a diagnostic if 
no objects are found. 

Left+ Middle Draws a line from the mark to die point of the click, of current line width. 'Hie line is 
eidier horizontal or vertical, depending on which difference in position is larger. This is a 
faster way of drawing lines Uian using die menu. The mark is moved to die point of the 
click, to facilitate drawing a series of connected line segments. 



Middle + Right 



Adds die object near die click to the selection. This is in contrast to the Middle Button, 
which causes exactly one object to be selected. Use this command to select several objects. 
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Right Button Pops up a command menu, as described below. 

More advanced commands are available on the menu as follows: 

Quit Exits without saving the illustration. Usually the Write command should be used to save the 

file, so if there have been changes since the last Write command, confirmation is requested. 

Line Width Pops up a menu of default line widths. Select the desired new width from 1 to 8 units. Clicking 
outside tlie menu results in no change. 

Delete The selected objects are deleted. 

Unsclect A click is requested; the object near that click will no longer be selected. 

Draw Line A click is requested, and a horizontal or vertical line is drawn between the mark and the 
position of the click. 

Add Text A line of text is requested, and the text is added at the position of the mark in the current font. 
Modify Text Selects another menu for commands used to modifying text. 
Write Writes tlie illustration back to the file given on the command line. 

Stretch Line Position the cursor near one end of the selected line, and hold down a button. The end of the 
line will move following the cursor until the button is released. (Available only in tlie native 
V-System version.) 

* 

Move Position tiie cursor anywhere in any view of the illustration and press any button. The selected 

objects will follow the cursor until tiie button is released. (Available only in die native V- 
System version.) 

Copy Position die cursor anywhere in any view of the illustration and press any button. A copy of the 

selected objects will follow the cursor until the button is released. (Available only in the native 
V-System vereion). 

Box Move die cursor to one corner of tlic box, and press any button. While holding down the 

button, position die opposite corner of Uie box. The box will be drawn in die current line 
width. The box can be aborted by pressing all tiiree buttons at the same time. (Available only 
in die native V-System version.) 

Select Area Move die cursor to one corner of the area, and press any button. While holding down die 
button, position the opposite corner of the area. All objects within the area will be selected. 
(Available only in the native V-Systcm version.) 

Debug l^nablcs several debugging print statements, for maintenance use only. (Available only in UNIX 
version.) 

The following commands arc used to modify text: 

Edit Text The selected text is stuffed into die VG'I'S line buffer, and edited by die user. 

Default Font Displays a menu of fonts to become the new default font, for Text added witii the Add Text 
command. 

Change Font Displays a menu of fonts to be die new font for the selected text. 
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4.5.3 Selecting Alternate Fonts 

Two text font/size combinations are available in SIL format, with regular, bold and italic faces in each 
font/size combination. Default fonts are Helvetica? and HclveticalO, with Helvctica7B, the bold face, 
Helvetica?! the italic face, etc. A third font, Template64, is used to draw circles and diagonal lines. 

Other fonts can replace Helvetica by creating a file with the name filename, fonts. This file contains the 
names of the fonts to be used, one per line. Comments are indicated by a # character at the start of a line. 
The default fonts are acceptable for illustrations to be included in papers, but for slides larger fonts like 12 
and 18 point should be used. Thus, for example, the font file: 

# font file for si ides 
He1 vetlcalZ 
He1vet1cal8 

could be used when making slides, A simple command to list the defined global symbols in the font library 
can be used to determine what fonts are available. 

4.5.4 Generating and Previewing Printed Copy 

A related program called silpress produces printed illustrations from SIL format files. Alternate fonts 
can be selected as in the s 1 1 ed 1 1 program. The command line: 

silpress filename. si 1 
converts tlie named illustration into a printing format file and queues it for the local laser printer. An option 
is available to retain the printer format file, to merge the illusti'ation into a document produced with the 
Scribe or TpX document compilers. It may take several iterations to get proper positioning and size, but it is 
faster than using a scissors and paste. The show program can be used to preview documents including 
illustrations before they are printed. 

4.6 Summary of Implementation Status 

Virtual Graphics Terminal Servers have been implemented for five varieties of SUN workstation, with two 
kinds of frame buffers. Interface libraries have been written in C and Intcrlisp. i hc C interface for UNIX is 
callable from other languages such as Pascal. Implementations for die iRis worksUition and VAXStiUion are in 
progress at the time of tliis writing. 

Current applications Include: 

• Emacs and an Rmacs-like text editor [21], 

• a VLSI layout editor [42], 

• a font design system [74], 

• a font and bitmap editor, 

• two document illustrators, 

• a document prcviewer, 

• some distributed games, and 

• a variety of display tools for vector graphics and raster images. 

All applications may be run directly on workstiitions if they have enough memory. Many may also be 
available remotely, under systems supporting appropriate network protocols and interface libraries, such as 
V ax/Unix or DHcSystem-20/Toi>s-20. Since all interaction goes tlirough tlic VGTS, other clients include 
executives and any remote applications accessible via-Tiii.NF;r-stylc protocols. Thus, wc have implemented 
clients of types A through D in Figure 3-5. With respect to short-circuiting, the VG'I S handles cursor control, 
hit detection, zooming, line-editing, and all screen management functions. 
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The implementation is reliable and fast enough to be used as a general computing environment. In fact, 
this thesis was written primarily using a text editor under the VGTS, and all diagrams were produced using 
the illustration editor described in the previous section. The experience gained from this use helped to judge 
the importance of criteria such as performance and reliability. 

Appendix C gives some details of the development of the VGTS, including other people who contributed 
soflvv'are to the effort. The prototype implementation took less than one year by tlie author, with slow 
evolution continuing by others. The next year was spent evaluating the design, which is discussed in the next 
chapter, and taking measurements, which will be discussed in Chapter 6. 
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— 5 — 

VGTS Design Rationale 

The partitioning problem is fiill of trade-offs: most design choices have both advantages and disadvantages. 
Some of these trade-offs are discussed in this chapter, along with rationale for the way decisions were made in 
the VGTS. One of tlic basic trade-offs is that for every "feature" to be added there is an associated cost. The 
cost must be balanced carefully against the potential benefit of the feature. Since this was a research project, 
we were concerned with developing the minimum functionality to create a tool for some prototype 
applications and taking measurements, rather than a system that could meet everyone's needs. 

Many of the factors interact witli each other. For example, the general partitioning issues discussed in the 
first section could cause performance problems discussed in die second section, and analyzed in tlie third 
section. The results of this analysis lead to the centralization decision given in the fourth section. Although 
centralization aids in portability and uniformity, it can cause problems with customizability. In the last 
section, the suitability of tlie VGTS design for the future is discussed. 

5.1 General Protocol Issues 

Some basic problems appeared when trying to define a good interface (VGTP) to the VGTS. Although 
total application and device independence Is a laudable goal, it can lead to a VGTS that supports too much 
fiinction for some applications and too little function for others. Both situations lead to excessive overhead: 
the first because the VGTS is doing too much; the second because the application must go to extra lengths to 
subvert the VGTS. For example, if the VGTS were tailored for the basic Sun workstation, it would include a 
variety of routines for clipping and scaling. However, in the iRis workstation these flmctions are provided in 
hardware by the Geometry Engine [381. GeneraPy, the IRIS provides considerably more functions tlian the 
Sun worksUition, favoring additions to the VGTP. Thus, the VGTS itself had to be structured as a collection 
of building blocks, and careful consideration was given to the intended range of graphics devices and 
applications. 

5.1 .1 Fundamentallmpliications of Partitioning 

Although networks should be as transparent as possible, physical distribution raises fundamentiil problems. 
In all cases we would like to limit both the frequency of communication and die amount of data transmitted at 
any one time. In some extreme cases this might require caching mechanisms on tlie workstation and 
necessitate complicated protocols to keep the workstation cache synchronized with the remote database. 

Nevertheless, we observed that most interactive programs could be divided into a frontetid that converses 
with the user and a backciid docs the real processing. This simple model of user interaction is illustrated 
in iMgurc 5-1. The ideal VGTS would provide a common user interface portion and avoid the duplication 
and inconsistent iiUerfaces that currently abound between applications, in so doing, it would short circuit tlic 
traditional interactive response cycle between the user and tlie application [55]. 
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Figure 5-1: User interactive response cycle 
Short-circuiting is possible at a number of different levels, including: 

• mousc-contrpUcd cursor: The updating of the cursor position is performed by the VG'TS in 
response to iiscr motion of the mouse (or similar pointing device). 

• screen management functions: These are necessary to allow multiple applications to run 
concurrently without interference. 

• hit detection: Applications are informed when a significant event occurs, such as selection of an 
object; they do not keep track of the cursor position. 

• editing: The VGTS supports editing so only some high-level indication of the editing changes 
needs to be communicated to the application. 

Higher-level short-circuiting, such as local hit-detection, provides: 

1. better response for those operations that can be short-circuited, 

2. better utilization of powerful workstation resources, 

3. lower demands on the network (for distributed applications), 

4. reduced programming required for applications, and 

5. lower processing demands for hosts. 

However, to support high-level short-circuiting, die VGTS needs to be provided with high-level information 

about input and display semantics. That is, tlic VGTP must allow the application to communicate the model 
that it is representing pictorially, not just the image of Uiat model, as is common in contemporary graphics 
systems. 

Imagine, for example, that multiple VGTs were mapped to overlapping viewports on the display screen. If 
the top VGT is repositioned on the screen, it and the previously obscured VG r(s) must be redrawn. If tlie 
VGTS does not have a model of the picture associated with the VGT, the VGTS cannot redraw the picture in 
its new position. Similar observations hold for panning and zooming. Instead, the VGTS would query a 
pt)ssibly remote application lo redraw the picture, a potentially time-consuming operation. Naturally, it is 
even more important for the VGTS lo support a model if it is to provide generic editing. 

The exact kind of model provided by tlie VG TS could have ranged from simple to complex. T'or example, 
even systems like GKS provide a rudimentary form of modeling tluough the Workstiition Independent 
Segment Storage capability. The power of using more general structure to define pictures has been exploited 
since the pioneering SKETCHPAD system in tlie early 1960s [135]. Ironically, a number of early graphics 
systems took this approach to its extreme by merging the application model and the display file into a single 
graphical data base [36, 112]. This approach fell into disfavor largely because it imposed a fixed 
representation on all applications. In light of distributed graphics, it is also impractical to support a single 
data structure spanning multiple machines. 
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A number of subsequent systems developed the notion of a structured display fde tliat encodes the 
hierarchical structure of figures, but leaves most of the application-specific information in a separate 
application model [51, 52, 126, 148]. The structured display file is partially redundant, but provides a 
reasonable amount of structure for high-level short-circuiting. In particular, compared to the more 
conventional segmented display file, a structured display file can provide better response when editing 
objects. Our initial application was VLSI circuit layout, which often requires drawing objects that are highly 
structured and regular [83]. 

The use of structured display files in tlie VGTS was motivated primarily by Sproull and Thomas's 
Structured Format Protocol, which in turn was motivated primarily by network issues of the sort discussed in 
this section [126]. However, that protocol was never fully implemented, primarily due to the lack of sufficient 
computing power in the terminals available at that time. 

In contrast, more traditional graphics packages do not retain object definitions at as high a level. This has 
three major performance problems compared to the VGTS. Firet, defining complex objects can require 
significantly more time, if those objects contain several instances of the same symbol. Second, editing existing 
objects is more time-consuming since the entire object must be redefined. Third, generating different views 
of objects is considerably slower, since the application itself must redraw each view. On the other hand, "on 
the fly" graphics could be faster under traditional systems since tlie VGTS does not permit an application to 
simply "write" on the display, but rather requires the application to repeatedly edit and redisplay an entire 
symbol. 

The evolution of graphics protocols can be compared to the evolution of general purpose programming 
languages. The simple bitmap oriented systems can be compared to assembly language, with total generality 
but lack of structure. The next step is procedure abstraction, which corresponds to languages like BCPL with 
control structure. The final step is to provide both control and data structure abstractions, such as languages 
like Pascal and Ada. 

Another worthwhile analogy is with low-level disk storage systems. F^rly attempts forced users to deal 
directly with the sector, track, and head allocation of disk files. The concept of "logical blocks" divides the 
disk into uniformly sized and sequentially numbered blocks. Interacting with disks in terms of these slightly 
higher- level objects makes impossible some of the clever optimizations done by early programmers. 
However, die advantages of tliis level make it almost universally used in modern operating systems. 

5.1.2 Replication Issues 

The replication of data (keeping multiple copies) that results from tlie partitioning described in the last 
section was another major design issue for the VG TS. In graphics systems, the multiple copies are usually at 
different levels of representation, and the reason for tlie copies is performance. The actual number of 
rcprcscntntions may vary, but most high-pcrrormiincc graphics systems maintain some kind of display list or 
display llle, which is intermediate in rcprescnUition between the application's datii structures and the final 
displayed picture [56]. 

¥ov example, an application usually reads some permanent data files and constructs an internal model of 
the objects being displayed. A structured display file contains information on structure and geometry, but no 
application information. The viewing process then displays this SDF with some viewing parameters, in our 
case on a bit map terminal. Thus, a typical situation may result in four levels of partially redundant 
information. This leads to several natural places to partition the data in a distributed graphics system, as 
illustrated in Figure 5-2. 

In each case the data structures below tlie thick line are stt)red on the workstation, and those above the line 
arc stored on some remote server machine. In traditional personal computers, everything would be on the 
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Figure 5-2: Possible data partitioning points 

workstation, witli tlie possible exception of data on a large archival file server to back up the personal 
computer's files. For large but diskless worksuitions, d e application program can still run on the workstation, 
but access the data files over a network. For smaller workstations, tlie structured display file is stored locally, 
but the application program runs on the machine with the file system. In the simplest of workstations, only 
the bit map is stored locally. 

Note that arrows only go one direction, from tlie higher level representation to the lower level one. Each 
representation can be geneiatcd from the next higher layer, which greatly simplifies the propagation of 
updates. Pipelining, including possible hai dware implementations, is much easier if the conversion is always 
in one direction. In actual practice, however, some amount of short circuiting can be done to provide faster 
feedback, since input has to travel in the rcveise direction. The architecture and implementations of the 
VGl'S keep this short circuiting to a minimum, with only a few simple local functions vastly improving 
average pertbrmancc. More research can be done in the future within this framework on even higher levels of 
short circuiting. 

The V-System allows all configurations of Figuic 5-2, although the fii*st (personal computer) and last (bit 
map tei'minal) have been thoroughly investigated in other work discussed in Chapter 1. The configurations 
labeled "small workstation" and "huge woi kslation" aie the focus of this work.- 



5.1 .3 Caching Issues 

One way to further reduce communications costs would be to write an agent for each application that 
maintains a cache of the main data base. Once a cache is in place, tlie usual problems of update arise. When 
should tlie cache updated and how much of it is updated at a time? For example, dicrc are two interesting 
cases in circuit layout: 

• When viewing the entire design it is unnecessary to maintain the details of tlie lowest levels. Iliis 
information may be omitted in order to maintain tlie representation for tlie higher-level structure. 
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• When viewing a specific component it is unnecessary to maintain the representation of pieces of 
the picture not now on view. 

Thus the agent would be constructed in such a way so as to maintain only the necessary data. Appropriate 
parts of the figure representation would contain the equivalent of invalid pages, leading to die equivalent of 
page faults. 

The ideal VGTS would provide most of this support without requiring that a special-purpose agent be 
written for each application. Although the current VG'i'S architecture allows caching, the current prototype 
does not implement any. The size of most SDFs rarely exceeds two or three thousand bytes, which is an 
insignificant amount of memory compared to the size of tiie VGTS itself. This and other possible VGTS 
extensions are discussed in the final chapter. 

5.1 .4 Transport Protocol Issues 

Once the higher-level protocols are decided upon, the transport and lower level protocols must be 
determined. Possible choices for transport protocol include datagrams, byte streams, and packet (or message) 
streams. Streams are an obvious choice because they generally provide a high degree of reliability, can be 
used with a wide variety of terminals and networks, and simplify programming the applications and the 
service. In addition, if the workstation and remote host interact frequently or in volume, high bandwidth is 
required, better achieved with virtual circuits. 

If bandwidth requirements are low, then the low delay of datagrams might be more appropriate. 
Furtiiermore, interactive graphics requires real-time communication, which places greatest importance on the 
most recent data. In contrast, streams under load tend to lose or delay new data in favor of old data. The 
graphical representation also impacted our choice. Since high-level information was being transmitted, the 
loss of a single datagram would be catastrophic. Th us, only "reliable" stream-oriented protocols were used. 

Fortunately, the V-System architecture allowed us to experiment with several of diese protocols. F^ch 
remote application must have an agent on tlic workstation, so the application and the agent may communicate 
with whatever protocol tliey desire. Since our prototype applications had relatively modest requirements, 
simple encapsuladons of die VGTP with standard byte-stream protocols were most widely used. 

5.2 Performance Issues 

Besides communication issues, performance was also kept in mind during every phase of the design of the 
VGTS. Without careful attention, many distributed systems can end up being slower than their centralized 
counterparts. In particular, many previous distributed systems have failed because of lack of attention to total 
system performance. On the other hand, although poor performance guarantees that a system will fail, high 
performance does not guarantee success. Other factors such as the various costs asst)ciated with high 
performance cannot be neglected. 

5.2.1 Code and Data Size 

Despite the falling cost of memory, main memoiy can still be a major cost of a computing system. In fact, 
no matter how much memory a computer system has, it seems to almost always need more. Eliminating 
duplication is one way to save memory, but often redundancy buys performance. A hardware cache is an 
example of such redundancy used to speed up a physical processor. Similar techniques to take advantage of 
redundancy were used in software, as discussed in Section 5.1.2. 
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Anotlicr way to save memory is economy of function: to not implement features tliat are rarely used, or 
that can be done with existing capabilities, unless they arc necessary. For example, some users might like to 
have blinking as a primitive attribute. Since blinking can be simulated by having the application program 
repeatedly add and delete an item from a symbol, blinking attributes were not included in the VGTS. This 
means that each application program must include code for blinking if desired, but the overhead is rarely 
encountered. On the other hand, diagnostics and error recovery are intended to be rarely used in properly 
written software, but many understandable error messages are included in the standard VGTS, since when 
they are used they can provide invaluable information. 

5.2.2 Resource Limitations 

The concern for memory costs is another prime motivation for the use of high-level display files instead of 
the more common bitmap approach. Note that the architecture does not explicitiy prohibit the storing of 
bitmaps, and in fact a biuiiap item type is supported. However, Section 4.2.1 described how the prototype 
implcmentauons redraw only from the SDF, with no biunap caching of overlapping areas necessary. The 
current architecture requires that to display large images the entire bitmap must be transferred into tlic VGTS 
for every change. This has proved adequate for simple image display tasks, or editing small bitmaps such as 
characters. For more intensive image processing applications, simple raster operations could be provided on 
raster objects to improve performance if necessary. 

Some display file approaches may severely limit the maximum size or complexity of objects that can be 
displayed. For example, many traditional graphics system support only one level of structure, the segment 
Since we are primarily concerned with the research community, absolute limitations should be avoided 
whenever possible. However, making some assumptions about maximum resource limitations may simplify 
the design or improve performance, for example, a reasonable limit on the number of virtual terminals or 
views might be an acceptable limitation, iso such limitations were included in the prototype VGTS 
implementation. 

5.2.3 Speed of Execution 

The two main measures of execution speed of interactive systems are response time and throughput. 
Response time is more important when the user has to wait. Many users of early workstation systems had to 
spend much of tlieir time waiting while an "hourglass" cursor appeared on the screen. Operations which take 
significant amounts of time should have been done in the "background". This requires a priority-based 
multi-process operating system, such as the V-System. 

For all other applications for which the user does not have to wait, throughput should be maximized. Since 
the hardware trends are to more specialized processors, a natural division is suggested between processes 
optimized for response time (interactive) and those optimized for throughput (batch). A fairly common 
scenario for usere of the VGTS is to be running an editor on the workstiition in one VG'l' while monitoring 
several long-running batch operations in other VGTs at the same time. 

5.3 Some Simple Models 

As discussed in the previous section, many attempts at distributed systems have failed due to poor 
performance. In addition to the inherent cost of die computation, the costs of communication between the 
parts of the distributed program are incurred. Thus the loial computation cost of a distributed program is 
almost always higher than the total computation cost of an equivalent centralized program. 
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There arc two approaches to improving the performance of distributed programs, both by identifying and 
overcoming these communication costs. The traditional approach is to improve the performance of the 
underlying network communication mechanism. The work of Spector and others on remote memory 
references is in this category [125]. A more promising approach taken in the VGTS was to decrease the 
amount of nctworic traffic by using higher-level protocols. In other words, reduce the frequency and volume 
of communication by making die applications more loosely coupled. 

For comparison, consider the many performance studies made of demand-paged virtual memory systems. 
Although performance can be improved by speeding up the handling of page faults, better results are usually 
achieved by reducing tlie number of page faults. For example, increasing physical memory, tuning the page 
size, improving the locality of the application, or using a better selection algorithm can make as substantial a 
difference as the speed of the disk. 

Although tliis section does not attempt an exhaustive analysis of the VG FS architecture, some very simple 
models can be developed. As in other simplified models of two-processor systems [132], a simple model is 
necessary before a more detailed one. Although some attempts have been made to model larger systems of 
many processors [131], these have mostly been theoretical models with very little total system performance 
data. At first glance one might assume diat the factor most important at any given time is the bottleneck, and 
construct a queuing theory model. The problem is that in a complete system the bottleneck is not so 
well-defined. 



3.3.1 Comparison to Cache Model 

A cache is a well-known hardware mechanism to improve perfomiance of a hardware design by taking 
advantage of locality properties of software [121]. The locality principle states that a program's references to 
data are not uniformly distributed, but instead concentrate around a set of locations at any given 
moment [108]. A small number of addresses arc responsible for a large fraction of tlie memory references. 
ThQ virtual memory concept is made possible by taking advantage of the principle of locality at the next 
higher level in the storage hierarchy. We can extend this concept to an even higher level, and take advantage 
of the patterns of usage for high-level graphics functions in the VGTS. 

In a distributed graphics system the processor in the cache model plays a role analogous to the workstation, 
and the main memory corresponds to other server hosts. The performance of a cache can be roughly 
characterized by four numbenj: 

^ local ^® average time for access to the smaller but faster resource. 

^remoie average time to reference tlie larger but slower resource. 

^ is the time it takes to communicate between tlie local and remote resources, 
comni 

p is the "hit" rate, or probability that an average operation can be handled by the local resource. 

This large communications (actor, I Is Uie major dl (Terence from llie hardware cache model, along with 
another component diat is common to both local and remote operation: 

^vgts average time taken by the VGTS for both local and remote operations. 

The average time for all operations is tiien; 

^ avg ~ P ^local ^comm ^ ^rcmotc^ ^vgts 

ITie ideal would be to minimize tliis time with respect to the various hardware and software tradc-ofFs 
mentioned In the rest of tills chapter. 
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In more concrete terms, this model represents a terminal by making p zero (or very small), so no operations 
are performed locally. The terminal role is acceptable when T^^jj^^, and T^.^^^^^^ are small components of the 
overall cost, which implies a very fast mainframe and high-bandwidth communication (or batch-oriented 
tasks). When p is near one, this models the personal computer configuration. Personal computers are fastest 
when Tj^j is small, which implies fast personal computers (or simple interactive tasks). 

When the task is too large to be handled by the personal computer or terminal configurations, tlie following 
approaches can make T^^^ smaller: 

1. Reduce T^qj^^^ (communication time) by using special protocols or network improvements. This 
requires measurements to determine if the actual bandwidth of tlie network or the transport 
protocols are the bottleneck. 

2. Reduce Tj^j by using a faster workstation. As we will sec by the measurement results, speeding 
up the processor usually has the desirable side-effect of also increasing effective network 
throughput, or reducing T^^n^. However, this cost must be incurred on every workstation. 

3. Reduce T^^^^^^ by using a larger, faster computer for the server host. This cost can be shared 
among all the workstations sharing a server. 

4. Increase p by caching information on the workstation or using high-level short circuiting so that 
more operations can be performed locally. Applications could also partition themselves to put 
more of their functionality on the workstation. Note that this usually implies an increase of die 
memory of each workstation. 

5. Reduce T^^^ by improving the performance of the VGTS itself. In fact, for many simple 
applications with insignificant computation demands, this factor could be the only important one. 

The value of short-circuiting has already been introduced. The next section goes into more detail on the 
relationship between the local, remote, and communication times in the VGTS model. 



5.3.2 The Time Dimension 

VGTS performance can also be examined by viewing the events along the time dimension. iMgure 5-3 
illustrates the time used on each processor resource for one typical interaction response cycle. Time 
progresses from lell to right. The first example is a pcrsoiuil coiiipulcr configuration. The next two lines 
represent the partitioning of the problem between a workstation and a server host. 

The variables in Figure 5-3 represent tlie following values: 

^input Represents tlie time to handle the input event. This is usually the same in both the local and 
distributed case. 



Swapin 



Represents the time to swap in or otherwise change contexts to the application program on the 
workstation. 



VGTS DESIGN RATIONALE 



63 



Personal Computer 

' I II ■ 



IT 



1 



T T 

Input Swapin 



_ SwapOut Display 

PC 



Workstation 





1 1 1 II 1 * 


Input 


|\\ / /| 


T 

Display 


Server 




T ^ 


T T T 
NetIn Server NotOut 





NeUn 



PC 



T, 



Server 



Figure 5-3: Simple request-response time model 

Represents the time to send the input event from the workstation to the seiner host, for the 
server to receive it, and possibly schedule and change context to the computation. 

Is the time for the computation to be executed on the workstation. 

Is the time for the computation on a server. Usually execution of the computfition is faster on a 
larger central server host dian tlie individual workstation. 



^ SwapOut l^cpresents the time to swap out the application program, or change context back to the graphics 
system. 

^NciOut 'Represents the time to send the results from the server host to the workstation, for the 
workstation to receive it, and possibly schedule and change context to the display process. 

^Display Represents the time to display the result of the interaction. 

The conclusion from Figure 5-3 is that it is faster to use the workstation/server split when the swap times 
plus tlie local computation time is longer than the round-trip network overhead plus the host computation 
time. That is: 

^SwapIn ^PC ^SwapOut ^ ^Nctln ''" ^Server ^NclOut 
is tlie condition for superior performance of the partitioned configuration. 

Since the V-System at the time of this writing supports neither paging nor swapping, is cither 

insignificant (for programs already fully loaded) or else it is the time to load the application program. 
Similarly, I's^apOut ^*^e time for a context switch. On the other hand, for the applications mentioned in 
Section 1.2.2 tliat must run on the server, the swap times are essendally infinite. On most pcmnal computer 
operating systems, swap times can be as high as several hundred milliseconds. Even wiUiout physical 
swapping, many operating systems have long context switching times. 

The time dimension analysis suggests the following techniques to improve performance: 

1. Reduce the Tj^^^j^^ and I'lsjctoui ^'"^^^ reducing delay in the network, increasing die bandwidth 
of the network, or increasing concurrency in the network overhead. 



64 



PARTITIONING OF FUNCTION IN A DISTRIBUTED GRAPHICS SYSTEM 



2. Have the server send results back to the workstation as soon as possible, since the rest of its 
computation can continue in the background concurrently with Tj^-^j^^y. 

3. Use tlie personal computer approach whenever possible with high timesharing loads. 
Timesharing loads add a queuing delay to Tg^rver' "^^^^^ could easily make it much higher tlian 
Tp^ on a powerful workstation. 

These models provide the framework for interpreting the performance measurements to be given in Chapter 
6. The following sections will discuss important design considerations tliat may not be directly related to 
distribution or performance. 

5.4 Application Multiplexing Alternatives 

One crucial job of tlie viewing service is to multiplex the single user and display devices to the possibly 
many application programs. This function is similar to that of die kernel or process manager of a general 
purpose operating system. 

5.4.1 Decentralized Control 

Most operating systems handle contention for tlie processor by letting one process have full control, then 
saving the state of tlie processor, loading the state of tlie next process to run, and letting that process have full 
control. A similar approach could be taken with graphics [35]. llie reasoning is that this will allow higher 
performance, since compiled programs usually have better performance dian interpreted programs. 
However, it is not necessary to have decentralized control to have compiled display lists; it is just a question of 
whether the application program or die viewing service does the compiling. 

A number of sophisticated object-oriented window systems have been built for personal computers with 
decentralized control, as discussed in Section 2.2. While these window system approaches work well for local 
applications, they do not extend well to remote applications, especially those written outside tlie framework of 
the particular language and workstation. Even systems that attempt to provide Uie object-oriented "up-call" 
Hmctionality in a distributed environment have resulted in centralized control [59]. 

One major problem with decentralized control is that current graphics devices do not always allow the state 
of the graphics device to be saved and restored. Another problem is diat application programs would be 
non-portable at die binary level even if there were workstations that used the same processor architecture but 
different graphics arcliitectures. This may not seem like a problem since source-level compatibility could be 
rettiincd, but it could result in a version "explosion" with many copies of every graphics application, each of 
which must be maintained in parallel with the olhci-s. Since both of these problems existed for the SUN and 
Iris workstations, the decentrali/.cd approach was not possible for die prototype implementation, riic 
original motivadon for virtual terminals (sec Section 2.3) was to eliminate Uic // J /// vereion problem. 

5.4.2 Centralized Control 

The VGTS, on Uic other hand, is designed to operate in a environment composed of a variety of 
applications, programming languages, machines, and networks, with widely varying terminal interaction 
requirements. A centralized approach, rarely tiiken in bitmap graphics systems, communicates a list of objects 
to be drawn to die viewing service, and die viewing service actually renders the objects. This virtual terminal 
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approach, previously introduced in Section 2.3, was talccn in the VGTS due to the advantages for portability 
and partitioning. 

It is not a contradiction (as it might seem) that partitioning implies centralization. Centralized control was 
used in the VGTS to provide adequate performance despite expensive communication. The actual costs of 
communication will be measured in Chapter 6. Another side benefit of centralization is conservation of 
memory. Each application program is smaller because it does not need to be linked with die graphics library. 

5.5 Uniformity and Portability 

Another set of issues concerns different aspects of uniformity. The general problem associated with 
unifoimity is that, almost by definition, uniformity may restrict flexibility. The goal was to restrict how things 
are done, but not what can be done. 

5.5.1 Device Independence of Applications 

Since worlcstation hardware is changed constantly, software developed on one icind of workstation usually 
does not rim on other worlcstations. One traditional approach to this problem have been query operations. 
Application programmers may take advantage of query operations to change behavior depending on the 
results of tlie query [28]. This is a highly restricted form of device independence, that requires premeditation 
by the applications programmer of all possible devices with which the program will ever run. 

Device independence has been recognized as a goal for quite some time, but is even more important 
today [60]. In fact, technology can progress so ftist that by the time an application is finished, totiilly new 
graphics devices may be available that were not even anticipated at the time the application was designed. 

For example, the prototype VGTS took about one year to develop, another year to measure and a final year 
to evaluate. In tJic meantime, the architecture of the SUN workstation had changed drastically, so the 
prototype implementation no longer worked on the new workstation. If tlie VGTS architecture had been 
tailored to tlic original workstation, then all the applications developed during these years would have to be 
rewritten. Instead, as soon as the new version of the VGTS that handled the new workstation was installed, all 
client programs could be run immediately, without any modifications. VGTS changes were limited to one 
low-level module, tlie drawing manager, as indicated in Figure 4-1. 

5.5.2 Uniformity of User Interface 

In addition to uniformity across different hardware devices, uniformity across different software tools is 
another desirable goal. Powerful hardware like bitmaps and mice provide the opportunity for more advanced 
interfaces, but also can cause chaos if each application chooses its own user interface. Kvcry programmer has 
his own idea of what is "right" and Uiose tastes may not match tliosc of the intended users. One partial 
solution to Uiis problem is the user interface management system concept which isolates the operation of a 
program from die details of how Uiose operations are invoked [143]. 

llic VGTS provides a step in this direction, witii the following user interface standards: 

• Pop-up menu feedback is implemented inside tlic VGTS. The view manager menus as well as 
tliose provided by applications are handled unifonnly. 

• A common line editor provides simple editing functions like character and word delete to all 
applications requesting keyboard input 
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• Bannei-s provide a common mechanism to indicate some concise status information, such as the 
name of the program currently executing. 

• All screen management, such as zooming and moving of views is done uniformly tlirough the view 
manager. 

• Other conventions and library packages are provided as suggestions. For example, pressing all 
tliree buttons simultaneously signals an abort to most programs. 

The result is that users quickly learned how to use new tools, instead of having to adapt to the whims of the 
implementor of the new tool. 

5.5.3 Portability of Implementation 

It was found to be easier to modify the code of the first implementation to handle another kind of 
workstation than to start from scratch. Several techniques were used to aid in portability: 

• Restricting the range of hardware. In our case, the VGTS was targeted to higher-end workstations 
and future higher, performance hardware instead of the lower cost popular personal computers 
currently being mass produced. 

• Using a high level language. The VGTS was written in the C programming language [71|, C 
compilers arc widely available for many computer architectures. The Unix timesharing system 
has been ported to many different architectures successfiilly by using C [66]. 

• Using a standard computer architecture. The prototype VGTS implementation was on the 
Motorola MC68000 architecture, which has several different implementations used in many 
commercial products [100]. 

• Attention to modularity and isolation of machine dependencies. This was only achieved by 
actually supporting two or more devices with the same source code. Once tlie system worked on 
two machines, the third was easier, and so on. The first few efforts detected subtle hidden 
machine dependencies that would otherwise be overlooked, such as byte ordering problems [40]. 

Portability was another of many properties greatly helped by economy of features. A small system was 
inherently easier to port than a larger system, l^'or tliis reason many attractive features were not included in 
tlic VGTS design unless they were, found to be necessary. For example, some users requested up/down 
encoding of the keyboard, or advanced support for special function keys. Unfortunately, the implementation 
already worked with about ten types of keyboards, some of which did not have up/down encoding or special 
function keys. 

Although the trend to faster but cheaper graphics workstiUions is unmistakable, the time between tlie start 
of a design and its production is usually underestimated. For example, a major computer manufacturer 
announced a workstation product and demonstrated it in July of 1982. in tlie fall of 1982, a research contract 
with Stanford was negotiated that included porting the VG'I'S to this new workstation. Uy the summer of 
1984 the project shifted efforts to a newer kind of worksUition. J Iardware progress had been so gieat lliat tlic 
workstations were obsolete before tlicy were delivered. 

A more important problem with porting the VGTS was not technological but political. Most workstation 
manufacturers were unwilling to reveal low-level det<iils of their graphics devices. If they contained custom 
hardware, the manufacturer wanted to protect the trade secrets involved in the hardware, so other 
manufacturers could not use the same techniques. If tlie graphics devices were simple frame buffers driven 
by software, tlie low-level raster operation functions were proprietary, to prevent tlie use of the software on 
other machines. In our case we had no desire to pirate trade secrets, but we failed to convince the 
manufacturers that it was in their best interests to give us tlie information. 
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5.6 Customizability 

Unfortunately the goal of uniformity was in direct conflict with that of customizability. Although at first 
customizability seems attractive, there are many hidden costs. For example, people often work together on a 
single project in a research environment. Highly customized interfaces make exchange more difficult, if users 
cannot use their custom commands on other workstations. On the other hand, since researchers are often 
systems programmers tliemselves, they have irresistible urges to change a program that tlicy do not like. If the 
interfaces arc not designed carefully and fiexibly enough, users will develop dieir own versions of the system 
anyway and the goal of uniformity is lost. 

5.6.1 Customizability by Programs 

The author of a program may want to specify some slightly device-dependent "hints" about the display 
process. For example, a program may have information on the size of some object or its desired location on 
the screen. The program may also wish to advise the VGTS on how the objects should be viewed. Although 
die vers architecture allows such hints, only one was provided in the prototype implementation: An 
application can declare die size of a default view. 

One example of a programmer who wanted customization of the viewing process occurred in an integrated 
VLSI layout editor and design-rule checker. The author of such a program requested the ability to position 
an item within a view, so that a design Rile violation could be centered in the viewport. Such a feature could 
easily be added by creating another VGT with the item as its top-level symbol, and then defining another 
default view with die desired coordinates. The view manager could also include commands to center a view 
on coordinates typed by a user, instead of pointed to by the mouse. Therefore, die view manipulation 
capability was not added to the VGTS client interface. 

A common argument is that programs should be able to perform any ftmcUon diat a user can perform. This 
is not provided in the current VGTS, since the user interface deals with views and physical screens, while the 
application interface intentionally hides these objects and deals with graphical items and virtual terminals. 
One area of future research is die design of a different kind of interface Uiat could be used for customized 
view management. However, it is important to make die clear distinction between non-uniformity on the part 
of die application tools, and customization of diose tools on the basis of die user. . 

5.6.2 Customizability by Users 

A user may want to specify a profile to tailor certain aspects of the user interface to his or her needs. For 
example, novice users may want an interface that is easier to learn or in which it is harder to make mistakes, 
while expert users want more powerful interfaces with commands available quickly. In addition, many 
aspects of user interfaces arc a matter of personal taslc. With respect to screen management, some people 
prefer to use arbitrarily overlapped viewports as implemented by the prototype VG TS, while others prefer to 
use die tiled approach, in which the view manager causes views to exactiy fill the screen without overlap [1401. 
Another open question is the proper form of menus. In the current implementation, one button click causes 
die menu to appear and another causes the selection. I his reduces die probability of errors when Incorrect 
button combinations are given, but requires two user actions for each menu selection. Other systems cause 
the menu to appear when the button is pressed, and the selection to occur when the button is released. 

Some systems use profiles on a workstation or application basis, but diey should really be provided on tiie 
basis of user, since uscre and applications should be able to use any workstation. The VGTS architecture 
allows this customization of the view management process, but die current implementations do not realize this 
capability. Partially diis is due to die lack of a user identification concept in die current V-System, but also 
due to die fact that the conventions as implemented have proven reasonable in actual use. 
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5.7 Suitability for the Future 

The future in the computer industry is hard to predict in detail, but some general trends are certain. We 
wanted to take advantage of these trends whenever possible, instead of tying die design to technology that 
would quicicly become obsolete. 

5.7.1 Future Display Devices 

Larger, faster bitmaps, and special- purpose graphics hardware should become less expensive in the future. 
For example, while tliis diesis was in preparation, the Apple Macintosh was made available for about $1000 
with a University discount; this is less than most alphanumeric terminals. The Macintosh has a fairly small 
display screen and low- performance processor, but Uie mere existence of the mouse and bitmap display in a 
mass-produced product are encouraging. 

Hie Iris workstation is an example of a higher-performance and therefore higher-cost system, with custom 
hardware applied to the viewing process [39]. The current IRIS implementation renders the output primitives 
using a bit-slice microprocessor, and is too expensive for wide-spread use. However, the IRIS is indicative of 
the trend to applying special-purpose hardware to graphics systems. 

Current developments include "smart memories" that use special devices to perform rendering, including 
anti-aliasing and shading via ray-tracing, directly in the frame buffer [63]. Perfonuance can be enhanced 
fiirthcr by using pipelining and parallelism. With this kind of hardware the BitBlt model of operations breaks 
down. Instead of moving bits around, the interface to tlie hardware is at a higher level: declaring primitive 
graphics objects like vectors and polygons. 

There are two differing opinions on the effect of this advanced specialized hardware. One line of reasoning 
is that since all this custom hardware is so expensive, the raw graphics device must be used at a very low level 
to avoid wasting any power. The other line of reasoning is tliat new hardware can be used to allow 
programming at a higher level, with straightforward, simple, and elegant approaches replacing tlie special 
mechanisms necessary on slower hardware. The fii'st opinion appeals more to tliose who design and market 
the hardware, while the second appeals to those who develop the software and use tlie workstiitions. Since 
software costs are becoming increasingly more important, in tlie long run the elegant software approach 
should dominate. 

As the VGTS was designed, it was hard to predict what the future held, but one tiling was certain: there 
would be many more changes in the kinds, quality, and cost of graphics devices. One good way to take 
advantage of these new devices, given this uncertainty, was to use abstract, high-level interfaces and 
concentrate on portability as done in tlic VGTS. 

5.7.2 Future Computer System Organization 

Ironically, the pereonal computing trend may be short-lived. Computer systems are still expensive, and 
people can not alford fully configured personal computers. On tlic other hand, microprocessors are almost 
free, and getting cheaper. The cost of a jnicroprocessor should eventually approach the cost of a memory 
integrated circuit, so despite the increasing densities of memory, the trend should be to less memory per 
processor instead of more memory per processor. The result should be computer systems tiiat consist of many 
microprocessors working together. 

For example, the cluster of workstations for which the VGTS was developed consists of about ten diskless 
SUN workstations connected with a local network to three Vax-11/750s, one Vax-1 1/780, and a shared 
DECSystem-20. In fact, each of the workstations is really a multiprocessor in its own right. In addition to die 
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MC68000, there are simple finite-state machines to refresh and update the frame buffer, a bit-slice processor 
to handle the Ethernet, and microprocessors in the keyboard and mouse. 

For these reasons, protocols that treat the workstation as a terminal (that is, partitioning below the VDI 
level as illustrated in Figure 2-2) are not very interesting for the future. The main limitation with these 
protocols is that they assume only one connection at a time. Since future computer systems will probably 
have many processors, and a single user will probably use many processors at once, the VGTS should allow as 
much concurrency as possible. Concurrency is a useful concept both at the haidware level (as many 
computers as possible should be kept busy) and at the higher levels of user interface (the user should be able 
to have many tasks in progress at the same time). As a first step, the VGTS provides tlie graphics operations 
in a separate process, instead of as functions called by tlie application programs. 

5.8 Backward Compatibility 

Although planning for the future is important, the VG I'S design did not ignore the past. It is unreasonable 

to expect all software to be rewritten for every new system. For this reason, one VGTS goal was to be able to 
take advantage of as much existing software as possible. A similar approach was taken in the Bruwin virtual 
terminal system [96]: the terminal manager was designed to take advantage of existing tools, instead of being 
the focus of all new developments. Even though Bruwin provided support for only text on a conventional 
graphics device directly connected to a timesharing system, it proved to be a useful tool. Similarly, the VGTS 
also was able to access applications running under the Unix timesharing system through remote execution. 

5.8.1 Encapsulating Existing Facilities 

For example, the V-System itself (including the VGTS) was compiled on a Vax/Unix timesharing system. 
Eventually more sofl:ware development tools were ported to the native V-System environment. The ability to 
run the tools under Unix greatly eased the transition. Many specialized or proprietary programs arc still 
accessed througii the Unix server interface. 

In addition, tlirough the use of terminal emulators and user TELNirr programs, a VGTS user can mn 
applications anywhere tliroughout the Arpa Internet. This, remote terminal capability has turned out to be 
one of tiie most heavily used features of the current implementation. J'he next chapter will describe some 
experiments using even interactive graphics programs in tliis manner. Fortunately, many tools can be 
accessed in a batch fashion, so there is little performance degradation when they are executed remotely. For 
example, tliis tliesis was produced with a document compiler that ran on a Unix server host 

5.8.2 Relation to Standards 

Another way of taking advantage of the past is to follow standards. The graphical facilities of the VGTS are 
similar lo those several existing grapiiics packages, including those conforming to the Core [147] and 
GKS [64] stimdardi/iition efibrts. The principal differences arc: 

1. standardized support for object modeling as well as viewing; 

2. hierarchical structure of objects; 

3. the ability to handle multiple, distributed applications simultaneously; 

4. less flexibility in terms of attribute and coordinate transformation facilities. 
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In general, the standards remain oriented toward a single, dedicated host, and pay little attention to 
distributed systems issues, especially the use of contemporary powerful bitmap workstations. Furthermore, 
there were no specific applications written for these graphics standards that had to be supported by the 
VGTS. Therefore die VGTS did not conform to any of these standards. 

Some recent graphics efforts are more in the spirit of the VGTS. Both NGS[24] and PiiiGS[4], for 
example, extended die concepts of GKS and Core to include structured display files, similar to the VGTS. As 
with previous standardization efforts, these go beyond the current VGTS in support for attributes and 
coordinate transformations. In fact, had they existed at the dme tlie VGTS was first designed (the fall of 
1981), we might have adopted many of their facilities outright. However, neither emphasizes distributed 
graphics (despite its name. Network Graphics System, in the case of NGS) or multi-application (window 
system) facilities. 

Table 5-1 summarizes how the VG rS graphics capabilities compare to some tiaditional graphics packages. 
The first colun-.n gives the name of the graphics package, and die second gives die number of dimensions in 
most operations. The next column indicates the kind of structures, including no retained segments in minimal 
GKS, simple one-level segments in CORE and GKS, execute segments (like procedure calls), and copy 
segments (like macro expansions). Ilie next column gives die approximate number of functions, which is 
always larger than the small number of graphics primitives. The last column gives the approximate years 
during which tJie design took place. 

Svstem Dimensions Structure Functions Years 

CORE 3D Segments 227 1977-1979 

GKS Maximal 2D Segments 185 1978-1982 

GKS Minimal 2D None 48 198M982 

NGS 3D Copy/Execute ' 181 1982-1984 

PiiiGS 3D Copy/Execute 180+ 1983-1985 

VGTS 2D Execute 30 1982-1984 

Tabic 5- 1 : Comparison of graphics packages to VGTS 

The Virtual Device Interface, VDI, could be used as a real terminal protocol in die VGTS, by developing an 
SDF interpreter that would generate VDI commands. The same observations hold with respect to 
NAPLPS [6]. This would allow a single VGTS implementation for ail devices meeting the specification. An 
interesting question is whether all device dependencies should be below tlie VDI (or equivalent) layer, or if 
common code could be used to simulate the commonly missing hardware capabilities. For example, the code 
to handle dashed lines for devices having only solid lines, could be written once instead of inside each device 
driver. There seems to be an unwritten rule that if a graphics device has any special hardware capabilities, 
then these "features" must be used, at almost any sacrifice in software structure. This could cause problems if 
devices arc supported that provide graphics primiUves in hardware diat are not included in the VGTS 
architecture. 



5.9 Summary and Motivation for Measurements 

This Chapter discussed die reasons behind the major design decisions taken in die VGTS. The next 
Chapter attempts to quantify the degree of these trade-offs. For example, die structured display file approach 
favoi-s highly structured pictures, and incremental edidng over inidal display. The penalty for initial display 
and unsti uctured pictures should be small compared to the improvement for structure. Since total system 
performance was considered important diroughout die design, some simple models were developed and 
examined in diis Chapter. The models show diat performance can be improved by reducing the frequency of 
communication and die amount of informaUon communicated. 
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The centralized control of the VGTS has benefits for uniformity and portability, but still allows some 
customization. Partitioning as exemplified by the VGTS should become more important as fiiture display 
and computing devices are introduced. On tlie other hand, users should be isolated from changing hardware 
by encapsulation of existing facilities and adherence to standards. Experiments are also needed to prove that 
performance is adequate compared to the older systems being emulated and replaced. 
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Measurements 

The previous chapter discussed many qualitative advantages of the VGTS design, such as portability and 
suitability to future hardware. Quantitative measures are also desired to provide a firm basis for evaluation. 
One ultimate measure of a system's success is whether people choose to use it to get work done, even in a 
research project. This criterion certainly applies in the case of the VGTS, since the high level of interaction 
enforced by the VGTS may trade off some functionality, flexibility, or performance. If the amount of tliese 
qualities lost is small enough compared to the advantages gained, dicn the approach may be worthwhile for at 
least some class of applications. 

For example, some graphics tenninals allow special effects like limited animation using tricks with the color 
map. On a workstation shared with other applications, these special mechanisms cannot be used, since 
resources like the color map are shared between several different applications. This chapter will show that 
careful design of VGTS protocols can make performance acceptably close to that of other systems that do not 
have the advantages of the VGTS. 

6.1 Nature of Performance Measurements 

Performance measurements have been taken for three benchmark programs, two for graphics and one for 
text, in a variety of test configurations. In addition, the illustration editor used to create the diagrams in this 
thesis was instmmented to theasure memory usage, construction, and display rates. 

6.1.1 Benchmark Programs 

The first graphics benchmark created a fully-connected 36-agon with a radius of 350 pixels, drawing 630 
vectors or 288,364 pixels. Thus the average vector size in this benchmark was 457 pixels. Since the picture 
was a fuUy-connected polygon, many different angles of vectors were used. This was intended to test the 
performance of traditional vector graphics functionality. Ilic action was repeated ten times, and the numbers 
listed are tlie mean often consecutive trials. 

All numbers given as vectors per second in this chapter refer to this same artificial benchmark, so tliey 
should be valuable for relative comparisons but not absolute limits. However, since most significant 
computation was done before the timed parts of this program, and tlie number of items in die picture is 
relatively large, the intent was to measure the peak rates of adding items to a symbol and then drawing that 
symbol. This would measure tlie rate of initially drawing a new picture. 

The second graphics benchmark was intended to test the effects of using structure on a simple picture of the 
kind used in a VLSI layout editor [42]. This benchmark drew an array of five by six nmos inverters [93]. 
Kach of these .10 inverters consisted of 26 rectangles, Ibr a loUil of 780 rectangles, all llllcd with one of four 
stipple patterns (which would appear as colors in a color implementation) representing the four NMOS layers. 
First the picture was drawn using a single-level SDK and adding all 780 rectangles individually. The second 
part of tliis test defined a contact cut symbol, then an inverter symbol, and then added 30 calls to tlie inverter 
symbol, with only 23 primitive items in the SDF. 

Although the regularity factor this drawing (the ratio of total items divided by defined items, or 30 in this 
case) is Hiirly high, modern VLSI designs typically have regularity factors in tlie same range, and the trend is 
to increasing regularity [83, 84]. In fact, many of the designs currently under development could never be 
possible with smaller regularity factors. Independent of tlie structure, tlie resulting image was tlie same, about 
400 pixels on a side. 
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The text benchmark programs simply wrote characters until stopped by the user. This behavior would 
occur, for example, when displaying a new page in a text editor. The characters were from a fixed-width font 
with each character eight pixels wide and 16 pixels high, or 128 total pixels per character. This was the 
standard font used by most applications except those doing specialized text display. It was developed by the 
autlior by manually editing the output of the Mei'AFONT type design program [74]. 

6.1 .2 Test Configurations 

The actual structures of the protocols and programs used in the performance measurements are illustrated 
in Figures 6-1 and 6-2. I'he benchmarks were conducted with tlie following communication configurations: 

Local Application amning on tiie same workstation as the one used for display. The application sends V 
messages directly to the VGTS. Since the application is on a separate team (address space), the V 
kernel's data transfer operations are needed to move information from tlie application to the 
VGTS' address space: no shared memory is used. This is illustrated in Figure 6- la. 

SUN-iKP Application running under the V-systcm but on a different machine, connected via Rtiiernet to 
another workstation, and using V-System IKP. As illustrated in Figure 6- lb, this involves the 
application using the same message-passing interface, but with kernels implementing the Inter- 
Kcrncl Protocol. 

Vax-ikp Application running under Vax/Unix, connected via Ethernet to the workstation, and using 
V-System IKP. As illustrated in Figure 6-2a, this involves the application writing to a pipe, which 
is read by the V-servcr program, which sends messages over tlie network to a V kernel. The 
workstation runs a simple program called fexecute which is necessary only because both the 
VGTS and die V-server are servers; they both are sent messages to whicii they reply, instead of 
initiating the sending of messages by themselves. 

Pup Application running under Vax/Unix, connected via Flhcrnet to the workstation, and using PUP 
Tni.Nirr. Figure 6-2b illustrates tliis configuration. The application uses pscudo-tty devices 
(ptys) to communicate with the PUP Ti-lnep server program Telser. ITiis program sends 
packets over the network to the workstation, where a user PUP Telnet program sends the 
messages to the VGTS. 

E-IP Application running under Vax/Unix, connected via Ethernet to the workstation, and using 
Internet 'iV.l.Nin\ 'iliis is Figure 6-2c. 'ITie application again uses pseudo-tty devices to 
communicate with the IP TEr-NET server Telnetd. \hc implementation of tlie transport 
protocol in this case is in tlie Unix kernel, and a separate program called the Internet Server on 
the workstation. The user Tiil, NET program finally sends the messages to the VGTS. 

A-IP Application running under Vax/Unix, connected via Flhernct and ArpaneI" to tlic workstfition, 
and using hitcrnet ri:i Ni- 1'. This is the same as l^lgure 6-2c, but with network including a gateway 
and an extension tlirougli tlic Akpani:i' backbone. 

Tests were conducted using stiindard 10 Mbit/second Ethernet unless otherwise noted. Tests were also 
peribrmed on the experimental 3 Mbit/second Etiiernet [41]. F^ach configuration used workstations with both 
8 and 10 MH/ MC68000 processor. For configurations involving Vax-ITs, 750's, 780's, and a 785 were used, 
and the tests were conducted during unsociable hours with correspondingly light loads. Real applications arc 
often run with high timesharing loads, but these are hard to control for tlie sake of tlie experiments. 

Even more difficult to control were changes to underlying soft.ware. Some variation through time inevitably 
occurred In tlie VGTS, other workstation software, and host software. For example, introducing new features 
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Figure 6-2: Server host configurations tested 

and fixing errors typically reduce pcrfonnancc, while casing bottlenecks found during experiments improves 
performance. Although each table in this Chapter compares configurations with similar software, two 
different Uiblcs may compare dissimilar versions. The dctiiiled results in Appendix I) include the date of each 
measurement. 



6.2 Summary of Performance Results 

Given the declarative nature of the VGTP, some measures of interest are: 
construction rate The rate that objects can be added to a symbol, without any display operations. 
batch rate 'Vhc rate that objects can be added to a symbol, and then displayed. 
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incremental rate The rate that objects can be added and displayed as each is added. 

display rate Tlic rate that objects can be displayed once they are defined. 

Construction rate is the best measure of the peak network offered load for distributed graphical applications. 
The batch rate takes into account display overhead, which is fairly independent of the network. Nevertheless, 
it gives the best measure of overall graphics throughput. On tlic other hand, the incremental rate gives a 
better measure of expected response, when interpreted as the maximum number of display transactions per 
second. Display rate is another measure of response for operations such as screen rearrangement or redisplay 
of defined symbols. 

Unstaictured vector graphics performance is summarized in Table 6-1. Additional details appear in tlie rest 
of die tables in tliis chapter and in Appendix D. In all of the tables, columns arc labeled with the test 
configurations listed above (local, SUN-IKP, Vax-ikp, PUP, E-IP, and A-JP). Most rows are labeled with 
(speed, host, ra'.e) triples, where speed is the speed of the SUN workstation processor (8 or 10 MHz), host is the 
type of VAX (750, 780, or 785), and rate is one of the rates listed above (construction, batch, incremental, or 
display). All numbers are in vectors or characters or rectangles per second, so larger numbers indicate better 
perfoi-mance. Results have been rounded to two significant digits, and should be taken as order of magnitude 
estimates only, due to the many factors involved. However, as we shall see, even these very rough 
measurements can be helpful to determine the feasibility of this approach. 

Table 6-1 presents tlie performance figures for configurations employing the most common processors, 10 
MHz Sun and Vax-750. As shown by tlie construction rate row, objects can be constructed at 440 
vectors/second for applications running locally, and 380 vectors/second for Ethernet-based applications. 
Overall graphics tliroughput, as shown by the batch rate row, is 220 vectors/second for local applications, up 
to 350 vectors/second for Ethernet-based applications, and 120 vectors/second for ARPANET-based 
applications. Incremental display permits 62 vectors/second for local applications, up to 87 vectors/second 
for Ethernet-based applications, and 39 vectors/second for ARPANiri'-based applications. Actual display rates, 
shown in Table 6-3, are on the order of 430 vectors/second, or .2 million pixels/second, or 5 
microseconds/pixel including all display overhead. 



Vectors/second 



Confieu ration 


L(x:al 


IKP 


PUP 


R-IP 


A-IP 


10, 750, construction 


440 


380 


200 


220 


130 


10, 750, batch 


220 


350 


200 


220 


120 


10, 750, incremental 


62 


81 


58 


87 


39 



Tabic 6- 1 : Summary of graphics performance 



The text results are summarized in 'i'able 6-2. Throughput is 7700 characters/second for local applications, 
up to 4300 cliaractei's/second for local net-based applications, and 1900 characters/second for 
ARPANirr-based applications. Additional details appear in Tables 6-4 and 6-5. 

Characters/second 

Configuration ■ l.ocal IKP PUP IrIP A-IP 

10, 780. text 7700 4300 1600 4300 1900 



Tabic 6-2: Summary of text performance 
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6.3 Feasibility Evaluation 

The most gratifying conclusion is that tlic VGTS performs better than many systems that researchers are 
currently using. Traversing the structured display files to refresh the screen is within 25% of the speed of the 
bare hardware, accessed through a package of low-level graphics primitives [22]. Symbols can be constructed 
at about the same rate as they can be displayed. Lastly, as shown by the incremental rate row in Table 6-1, 
applications may issue around 60 EditSymbol - Addltem - EndSymbol sequences per second. This is more 
than the 10-20 updates per second needed to make limited forms of animation possible at the application 
level, without any need to resort to display file compilation or other special techniques. Display file 
compilation is still possible in this architecture, and may be needed for graphics devices that are faster in 
relation to processor speed. 



Perhaps the most important concern is how the VGTS performance compares to more traditional graphics 
architectures. Table 6-3 compares a number of different "graphics pipelines" to help make this comparison. 
The pipelines include the following: 

1. An application writing directly to the frame buffer using the standard, highly optimized 
implementation of vector drawing. 

2. The VGTS refreshing the frame buffer from a structured display file. 

3. An application program on a server host using tlic VGTS to construct and display the picture. 

4. A local tipplication using an alternative "Window System" [10]. This is an example of the more 
common graphics model in which the application is in control of all drawing. 

5. An application program on the worksUition using tlie VGTS to construct and display the picture. 

6. An application writing directly to the frame buffer using a straightforward implementation of 
vector drawing. 

By comparing the performance of these pipelines, we can estimate upper bounds on tlie cost of the major 
arciiitecturai features of the VGTS. Lines 1 and 2 show about 25% performance degradation for all drawing 
overiiead in the VG TS. The principal costs arc: 

• Coordinate traiisfornuitions. Applications specify objects in a virtual coordinate space, which 
must be transformed inU) device coordinates. This could be done at SDI'' creation time using a 
form of display file compilation, but is currently done at draw time, avoiding the use of expensive 
arithmetic operations like multiplications by using shifts. 

• Clipping. Objects are displayed only within window boundaries. Objects tliat lie entirely outside 
of the window should not be displayed, but the parts of objects that lie partially within the 
window should still appear. 

• SDF Interpretation. 'Hie SDF structure was designed to be interpreted very quickly. With an 
overhead of one pointer reference per item, this constitutes very little of the drawing overhead. 



Graphics pipeline 



Vectors/second 



L Local application -» frame buffer (clever code) 

2. VGTS -5^ frame buffer 

3. Remote application ^VGTS frame buffer 

4. I^al application ->W -s^ frame buffer 

5. Local application .^VGTS frame buffer 

6. Local application -> frame buffer (straightforward code) 



570 
430 
350 
300 
220 
190 



Tabic 6-3: Effect of graphics pipeline 
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Lines 1 and 4 can be used to estimate the cost of centralized control. The W system is representative of the 
"minimalist" approach, with actual drawing centralized but few of the otlier features of the VGTS. Thus the 
47% overhead of W can be attributed primarily to: 

• Message overhead. This will be incurred whenever the graphics service runs as a separate process 
from tlie application. Besides tlie time for the actual message passing and context switching, the 
operations must be encoded into and decoded from the message. 

• Data movement. This is the cost of copying information from the address space of the application 
to the server, incurred whenever the server is not linked into each application. 

Comparing line 4 to line 5 indicates a 27% performance difference when using die VGTS instead of 
W. Although some of this may be due to SDF" interpretation overhead, most is due to die following VGTS 
features: 

• Client stt'cam interface. The prototype interface library encodes all graphics operations into a 
stream of bytes, and uses die standard V I/O protocol. This allows for I/O redirection, even 
among machines with different byte orders. 

• Server stream interface. Tlic prototype server implcmentadon decodes the graphics operations 
from the byte stream and calls appropriate internal Hmctions. 

• Error checking. Tlie VGTS attempts to do most error checking, such as verifying that table 
indices are within dieir proper bounds, at SDF creation time, so subsequent redraws will perform 
at full hardware speed. 

• Memory allocation. Memory must be allocated to die SDF display records for each new object. 
Once the memory is obtained from the system, diis involves only a simple pointer movement 
down the free list 

• SDF Saying. The actual overhead for saving the display record involves storing the coordinates 
and attributes (usually insignificant) and calculating the extent of die currently open symbol. 

Despite diese costs, die VGTS distributed rate (line 3) is higher Uian W (line 4). This shows that a significant 
amount of the overhead is incurred on the client, which results in a benefit from concurrency. It is, in fact, 
standard protocols such as V 1/0 and the byte stream concept diat facilitate distribution. 

Note that almost all of these costs must still be incurred even if SDKs were not used to retiiin die graphics 
information: die only saving would be the few microseconds to store into the display record. Of course, some 
overheads could be avoided by using only one process, one address space, screen coordinates, etc. but the 
resulting system would not have tlic advantages described in the last chapter. 

Finally, comparisons of application*— screen throughput show die VGTS at its worst case, since they do not 
take advantage of die display file. Hvcn diough the initial picture sometimes tiikes longer to appear when 
using die VGTS, once it is defined it can be drawn very quickly. I'or example, in response to screen 
man;igcnicnt opcraLlons, any W-likc system would require the application to redisplay its contents at the 300 
vectors per second rate, while the VGTS would redisplay at 430 vector per second, a 43% performance 
advantage. 

A simple qualitaUve measure of text performance is how the VGTS compares to standard RS-232 9600 
baud terminals, which generate about 940 characters per second. For example, consider a typical page 
forward command in a screen editor which changes about 1000 characters. On a 9600 baud RS-232 
connection diis would take about one second. With die VG TS it takes about a fifth of a second, which is fast 
enough to seem instantaneous to most users. 

The remainder of this chapter will attempt to show die effect of varying different parameters, and evaluate 
die effects to die limited extent possible in die configurations available. These parameters include: 
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• Speed of the workstation and graphics device 

• speed of the remote host (if any) 

• speed of the network 

• choice and implementation of transport protocol 

• level at which information is communicated, including characteristics of the virtual graphics 
terminal protocol 

6.4 Internal Factors 

For many application programs with large processor demands, the importance of the speed of the graphics 
can be insignificant compared to the importance of the speed of the application. These programs are ideally 
suited to the VGTS architecture since the application can be rim on a larger, specialized, high-performance 
processor instead of the workstation. Tlius, the major concern is when the frequency of interaction is high. 

Even though the VGTS was designed for efficient partitioned operation, it is still good at local operation. 
As we shall see, the most important factors affecting the performance of the VGTS arc the same as those 
affecting most other programs. This might be considered as unfortunately mundane, but it means that the 
VGTS can take advantage of the many well-known techniques for making typical programs run faster; there 
are no inherent performance reasons to prevent the use of VGTS concepts. 

6.4.1 Effects of Graphics Package 

One of dicse important factors that is often overlooked, is that for any program, most of the time is spent in 
a small part of the code. In tlic case of the graphics benchmarks, much of the execution time was spent in the 
vector or rectangle drawing function. The Brescnham algorithm, which is usually the fastest, was used to 
draw vectors [20]. However, even a straightforwaid implementation of tlie fastest algorithm was much slower 
than an implementation using clever coding of the inner loops of the Brescnham algorithm. 

In the clever implementation, the vector drawing function compiles a custom-made inner loop for each 
vector. This takes a little more time to set up for each vector, but tliis initial time is kept small by using table 
look-ups. As seen in Table 6-3, using compiled vectors instead of straightforward coding yielded a 200% 
improvement in vectors per second on tlie draw rate. However, using tlie VGTS introduced some overhead 
on the drawing times since it is interpreting a structured display file. Table 6-3 showed diat the SDF 
overhead is very small compared to the large improvement from compiled vectors. 

Unfortunately, the speedup from chosing a good algoridim and optimi/Jng its inner loop is good for only a 
one-time increase In performance. Once Uie best algorithm is found and its inner loops are hand-optimized, 
more w()rl< will not result in more performance improvements. On the other hand, the cost of carefiilly 
recoding one module or writing a few lines of assembly code is usually small, so the return on the invesUnent 
is good up to a point. 

6.4.2 Effects of Processor Speed 

Another fairly obvious fact that is often overlooked is that the speed of an application is directly related to 
die speed of the processor on which it runs. Table 6-4 compares the performance of workstations that have 
two different basic clock rates, but are similar in most other respects. Use of 10 MHz SUN workstations 
instead of 8 MHz workstations yielded up to 22% improvement. The principal reason tliat the increase from 
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SMhz to lOMhz 68000 processors did not produce a 25% increase in tlie performance was that tlie lOMHz 
design required polling of the keyboard and mouse. Similarly, executing the application on a Vax-11/780 
instead of a Vax-11/750 yields up to 50% improvement (see Table 6-5). 

Vectors/second 

Configuration Local IKP PUP E-TP A-IP 

10, 780, batch 210 190 130 110 92 

8, 780. batch 180 150 110 99 88 



Charactei-s/second 
10, 780, text 7700 4300 1600 4300 1900 

8, 780, text 6700 3200 1400 3600 1800 

Table 6-4: Effect of workstation speed 

Two of the more surprising results relate to the benefits of distributed computing. First, applications can be 
expected to run faster when distributed between a Vax-780 and a Sun workstation than when run locally (see 
Table 6-6). Even if construction rates are lower in the distributed case, the concurrency from the use of two 
processors resulted in higher rates for both batch and incremental display. Second, some applications execute 
faster using a Vax-785 on tlic Arpanet than using a Vax-750 on the local net (see Table 6-7). Since the 
Arpanff is substantially slower than the Etiiemet and network communication in general /s slower than local 
communication, the conclusion is that CPU speed is the dominant factor in this instance. . 

Vectors/second 

Configuration IKP PUP E-IP 

10, 780, construction 510 210 170 

10, 750, construction 340 130 110 

Characters/second 
10, 780, text 4300 1600 4300 

10, 750, text 4100 1400 2300 

Tabic 6-5: Effect of remote host speed 

Note that Table 6-4 and 6-6 contain batch rates, to emphasize overall performance. Table 6-5, on tiic other 
hand, contains construction rates, to emphasize the performance of the processor executing the application. 
However, regardless of where the application executes, the workstation is always required to do some work, 
namely, to maint^iin and display the graphical objects. Therefore, performance is more sensitive to 
workstation speed than to remote processor speed. For example: whereas a 25% increase in workstation 
speed results in almost linear speed-up, a 100% increase in Vax speed results in at most 50% speed-up as seen 
in Tables 6-4 and 6-5. Note that Tables 6-4 and 6-5 were constructed with early versions of the protc^ols; 
later changes to tlie protocols increased the setisUivity of 11* to server host speed, but decreased the sensitivity 
of IKP and PUP. 

Vectors/second 

Configuration Local E-IP 

10, 780, batch 220 380 

10, 780, incremental 62 92 

Tabic 6-6: SUN vs. Ethernet-based 780 



One might conclude from these measurements that tiiere is little reason to distribute applications, since 
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Vectors/second 

Configuration E-IP A-IP • 

10, 785, construction 160 
10, 750, construction 130 

10, 785, batch 140 
10, 750, batch 125 

Table 6-7: ARPANirr-based 785 vs. Ethernet-based 750 

batch rates are comparable between local and remote applications. Performance should be improved as two 
processors are used. However, our benchmarks make no significant computational or database demands that 
would take advantage of faster hosts. Moreover, as mentioned in Section 1.2.2, some applications simply 
cannot run on the workstation, due to memory or language requirements, for example. Non-graphical 
applications can be expected to depend more on disk or operating system performance, softening the impact 
of proces5;or speed. On the other hand, compute-bound applications, including any that use floadng point, 
are impacted more heavily by host processor speed. 



6.4.3 Effects of Graphics Hardware 

Table 6-8 gives the effect of two measured frame buffers. The first line in the table refers to the original 
frame buffer which simplified graphics primitives by providing bit-shifting hardware. The second line refers 
to the frame buffer in which display memory is byte-addressed like all other memory. The second frame 
buffer is about 30% slower on vector drawing than the original frame buffer. However, creation is faster on 
the Sun-2, due to a slightly different I/O architecture. Although the Sun-2 is still about 15% slower for the 
total local batch rate, remote batch rates are sometimes higher due to CPU saturation. 

Vectors/second 

Configuration Draw Create Ibtch H-IP 

Sun-1,750 430 440 220 220 

Sun-2, 750 290 470 180 170 

Tabic 6-8: l^ffcct of frame buffer 



6.5 Protocol Factors 

Hie nature of the applications and of the information Uiey communicate among tlieir distributed parts 
make the network behave differently from what might commonly be expected. The use of high-level graphics 
protocols reduces the dcgnidation that is experienced between dilTcrcnt bandwidth networks. This can 
infiuence the choice of network protocols since the performance penally ofacccssing a high-performance host 
over a long-haul internetwork instead of a less powerful host located on a local network may be outweighed 
by tlic difiercnce in host capabilities. 

From another point of view, die higher-level protocols tend to increase the CPU cost of fast 
communication. This may be an advantage, due to the decreasing costs of CPUs compared to 
communication, but also means that less of the CPU is available for other tasks. In concrete terms, the 
protocols are "high level" since they deal with graphical objects like lines and polygons instead of low-level 
bitmap operations, and they take advantage of structure. 
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6.5.1 Effects of Structure 

As discussed in Section 3.4, the VGTP allows objects to be defined in terms of graphical primitives such as 
vectors or rectangles, or in terms of other objects. Once the objects are defined, they can be made to appear 
on or disappear from the screen with short commands of only a few bytes. The perfoitnance advantages of 
retaining the display files on a dedicated workstation, introduced in Section 5.1, have been known for some 
time [88]. The following tests were performed with a program that used the structuring facilities of the VGTS 
to create 30 instances of a symbol consisting of 26 rectangles each. 

The results for the structure benchmark are given in Table 6-9. The first thing to notice is the very low rate 
for incremental performance, especially over long-delay networks like the Arpanet. By batching and 
pipelining the operations, performance increases by a factor of 7 for local operations, 30 for Ethernet 
operations, and 40 for Arpane t operations. Using structure instead of an unstructured list of primitive items 
increases performance again by factors of 3 to 4 for both local and remote operations. 



Rectangles/second 



Confieuration 


Local 


E-IP 


A-IP 


10, 750, incremental 


41 


5 


2 


10, 750, pipelined incremental 


61 


66 


36 


10, 750, batch unstructured 


310 


180 


81 


10, 750, batch structured 


1070 


670 


370 



Tabic 6-9: Effect of structure 



Some other interesting observations can be made from Table 6-9 that reflect the value of batching and 
structure. First, the time to define and display the picture for a local application was about 1 millisecond per 
item. This is roughly tlie time to perform a local Send - Receive - Reply sequence in tlie V kernel [31], so any 
protocol Uiat uses a message transaction for each item will be slower. Secondly, it is faster to run this 
benchmark over the Arpanef and use structure than it is to run the same program locally and use 
incremental or unstructured display. The latter is comparable to traditional graphics systems. It is also faster 
to run the program across the Ethernet and use structure than it is to run the program locally, even with 
batching. 

Structure introduces a slight amount of overhead, since the VGTS must trace Uirough the symbol data 
stiarcture. However, in this benchmark Uie structure interpretation introduced an overhead of about 20 
milliseconds out of about 900, or less than 3% of tlie local draw time. Thus there is litUc performance 
advantage to use a segmented display file instead of an arbitrarily structured one. By using a linear list instead 
of a linked list, display records could be 16 bytes instead of 20, or a 20% savings in memory. Unfortunately 
this would make insertion and deletion much more difficult. Moreover, the SDF representation is already 
quite concise, as will be shown in Section 6.5.3. 

6.5.2 Effects of Batching and Pipelining 

Comparing Uie batch and incremental rates in Table 6-1 as well as Table 6-9, shows the importance of 
batching. The original implementation of the VG TP employed a return value for each operation. In tiie 
current implementation operations are batched so that values are returned only after an entire sequence of 
operations (such as all changes to a given symbol) have been performed. This change reduced network delays 
substantially, yielding performance improvements of up to factors of 301 

The first two lines of Table 6-9 give tiie effect of another important change to the VGTP. By removing tlic 
return values from the EditSymbol and EndSymhol operations, even incremental operations could be 
pipelined, resulting in much more concurrency Uian the "stop-and-wait" protocol resulting from return values 
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on each transaction. The reduced message traffic caused an increase of 50% for local operations, and increases 
of factors of 10 to 15 for remote operations. In fact, remote incremental operations arc almost always faster 
than local incremental operations due to this concurrency. 

6.5.3 Comparison to Bitmap Protocols 

Many approaches to graphics within a distributed system use protocols based on bitmap manipulation. 
Unfortunately, bitmap protocols can be inefficient in both their bandwidth and memory utilization. By 
reducing tlie Icngtli of the descriptions of graphical objects, they are made independent of the structure of the 
bitmap as well as being smaller in both transmission and storage. 

The advantages of die SDF for memory usage are indicated in Table 6-10. In the vector benchmark, the 
SDF represented the fully-connected polygon with 20 bytes per item, or 12,600 bytes. This compares to die 
800 by 800 bitmap area, which would take 80,000 bytes. In practice, most pictures are even less dense dian 
the fully-connected polygon, so tlie advantage would be even greater. In particular, the SDF approach has 
the advantage as long as there are more tiiat 20 bytes of bitmap space for each item in the SDF. The rectangle 
benchmark shows that even without using structure, a factor of about two in memory savings is possible. 
Using structure, the 900 bytes used by die SDF is a factor of 37 less than the space for the bitmap. Similar 
large improvement factors in network bandwidth requirements will be discussed in Section 6.6. 

Bytes of memory used 

Benchmark SDF Bitmap 

vector 12,600 80,000 

rectangle, unstructured 15,600 34,000 

rectangle, structured 900 34,000 

Tabic 6-10: Effect of SDF on memory usage 

6.5.4 Effects of Transport Protocols and Their Implementations 

As noted for Table 6-5, three different transport protocols were used, with significantly different 
performance results. The V-systcm supports both a local protocol and two general intcr-network byte-stream 
protocols. The local protocol provides an interprocess communications facility between V-system processes. 
The two general protocols arc the Xerox PUP family implemented tiirough the RTP/BSP level, and tiie Arpa 
Internet protocol family implemented Uirough the TCP level. User TEi.Nirr programs exist on top of both. 
The network configurations were illustrated in Figure 6-2. 

Unfortunately it is very hard to compare only the effect of protocol design, because of many 
implementation issues that vary between the protocols. For example, the implementation of PUP BSP did 
not use any of the windowing features available in the protocol, resulting in much lower performance than the 
IP. More important, the packet si/.c used in the IKP inipleinentation was 1024 bytes, while both PUP and IP 
used packets of 100 or 200 bytes. On the other liand, the incremental rates for the IKP experiments were very 
poor, due to tlie fact tliat a Unix server process was polling every few seconds for output from a pipe, while 
the other protocols were interrupt driven.^rhus the implementation of tlie protocol may have a greater effect 
that any properties inherent in die protocol itself. 

F'ortunately we were able to experiment with different implementations of the same protocol. During the 
course of our experiments, Uiere were two major implementations of die Arpa Internet Protocol available for 



The Unix V-scrvcr could be modincd in 4.2 to use the se1 ect system call [68], which would eliminate this delay. 



84 



PARTITIONING OF FUNCTION IN A DISTRIBUTED GRAPHICS SYSTEM 



Vax/Unix systems. The first was done by Bolt, Beranck and Newman (BBN) and was for the 4.1 version of 
Unix [61]. The second was done by the University of California at Berkeley for the 4.2 version of Unix [68]. 
The relative perfonnances of these two implementations of the same protocol are given in table 6-11. The 4.2 
implementation is 14% faster for batch construction and display rates. The difference in peak throughput 
rates is even more significant, but even this higher rate is several orders of magnitude below tlie actual 
bandwidth of the network. Possible reasons for this will be discussed in the next section. 

Vectors/second 



4.2 4.1 

Configuration TP/TCP IP/TCP 

10, 750, construction 140 110 

10, 750, batch 93 81 

10, 750, incremental 7.8 4.8 



Table 6-1 1: Effect of TCP implementadon 

Table 6-12 indicates the effect of changing the relative priorities of the application program or the Telnet 
server program. This test was done using die PUP protocol on a local 10 Mbit/second Ethernet. The first 
column gives the results for normal operation. For the second column, tlie operating system gave priority to 
tlie Telnef server program. Batch performance actually decreased, since more network packets were sent 
For the third column, both the application and the Telnet server were given priority, which increased both 
the batch and incremental rates. However, as shown in the last column, the best performance was obtained by 
giving priority to the application. 

Vectors/second 

Telser & 

Configuration Normal Telser Application Application 

10, 750, batch 170 160 190 200 

10, 750. incremental 47 48 58 58 

Tabic 6- 12: Effect of Process Priorities 

Another interesting comparison is between remote execution on a timesharing host and execution on 
another workstation. Table 6-13 displays this comparison. 'Hie construction rate is about the same on the 
Vax/Unix system and on the V-System. The incremental rates on tlic Vax/Unix implementadon are very 
poor without pipelining, due to the high delay. Note, however, tliat die total batch rate and the pipelined 
incremental rate arc much higher on the VAX than on another workstation. This is due to the fact that tlicrc is 
actually little concurrency in the remote wori(station case, due to die synchronous Vikp messages. Much 
better performance could be obtained by replying to tlie message before it is processed, instead of after the 
operations are performed. 





Vectors/second 




SUN 


VAX 


Configuration 


IKP 


IKP 


10, 750, construction 


380 


380 


10, 750, batch 


190 


350 


10, 750, incremental 


29 


4.6 


10, 750, pipelined incremental 


44 


81 



Table 6-13: Effect of IKP implementation 
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6.6 Network Factors 

The use of networks implies both limitations in bandwidth and increased delays. All of the above factors 
(and our design and implementation) combine to render the actual network bandwidth insignificant. Table 
6-14 shows tliat although a 3 Mbit/sccond Ethernet is about 60 times faster than tlic 56 Kbit/second links 
used in the Arpanet, using a backcnd host on the local network yields less tlian a 50% performance 
improvement over using a backend host on the Arpanet^. Moreover, there was very little measurable 
performance difference between using the 3 Mbit/second experimental Ethernet ratlicr tlian 10 Mbit/second 
standard Ethernet [44]. The column labeled ElO-IP refers to standard 10 Mbit/second Etliernet. Although 
the Ethernet is about 180 times faster than the links used in the Arpanet, die Ethernet construction rates are 
less tiian twice the Arpanet rate. In fact, most of tlie difference in the total batch rate is due to the delay of 
the Arpanet and intervening gateway, not any bandwidth restriction. Earlier implementations of die 
protocols had even less of difference. 

Vectors/second 

Configuration E-IP ElO-IP A-IP 

10, 750 4.2, construction 220 230 130 

10, 750 4.2, batch 210 220 120 

Table 6- 1 4: Effect of network bandwidth 

These results can be attributed primarily to the level of communication as discussed in section 6.5.1, and the 
conclusion that processor speed is the usual botUencck. This is consistent with other measurements of 
Ethernet performance [120] that show very low utilization of the available bandwidth of the Ethernet, and 
comparatively long delays on the Arpa Network. Thus, these systems rarely approach the limits described in 
. analytical studies that concentrate on performance under heavy loads [145]. In fact, these protocols can be 
used on Very low-bandwidth communication links. 

Each Addltem call sends 20 bytes of data, so a construction rate of 230 items per second (the Etiiernet load 
given in I'able 6-14) corresponds to only 4600 bytes per second, or about 40 Kbits/second, about 0.4% of the 
Ethernet's bandwidth. Due to die small amount of data, graphics could even be possible over standard speed 
telephone lines. For example, at 1200 bits/second, a peak rate of 7.5 items/second should be possible. To test 
tills, die experiment was run successfully on a workstation over a 1200 bits/second telephone link. Several 
other rates were tested using point-to-point RS-232 connections at various speeds, with the results given in 
Table 6-15. 



Items/second 



Configuration 


1200 


2400 


4800 


9600 


P-IP 


10, 750 4.2, construction 


7.4 


14 


26 


54 


166 


10, 750 4.2, batch 


6.2 


12 


23 


46 


131 


10, 750 4.2, structure 


84 


142 


230 


320 


380 



Table 6- 1 5: l^ffcct of point-to-point communication rates 

For the structure benchmark, even at 1200 biLs/second, the measured creation rate was 7.4 items/second, 
very close to the maximum 7.5 calculated above. This rate is slightly less than linear in relation to the 
bandwidth, indicating that even at low speeds Uie CPU can be a factor. Moreover, the total rate when using 
structure was 84 items/second at 1200 bits/second, which is twice as fast as running die program locally with 
incremental drawing (the first entry in Table 6-9). Structure and lack of significant delays also makes this 



u 

In Tact, the experimental Elhcrncl Is really about 2.93 Mbit/second, 
the 56 Kbit/second of the Arpanct link! 



llic diflcrcnce between this and 3 Mbit/sccond is greater than 
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Structure rate faster tJian the batch rate for the Arpanet (the last entry in Table 6-9). Significant delays can 
even be seen in the local Ethernet IP results, as given in tlie last column of Table 6-15. The 9600 bits/second 
structure rate is only about 15% slower than using Etliernet, even though Ethernet has a raw bandwidth a 
thousand times greater. 

6.7 Human Factors 

The actual VGTS could be instaimented to take data during production use. This information would 
record the frequency of operations and die corresponding response time. A "user simulator" could be written 
to simulate a real user's command sequence, with suitable randomness. This could be used to tune the 
performance of the VGTS to match the user profiles gathered in the above experiments. More elaborate 
instrumentation results would be very interesting, but are beyond tlie scope of this thesis. 





ObiecLs 


Time 


Rate 


Bitmap 




Maximum 


365 


1370 


266 


40K 


7.3K 


Mean 


116 


485 


234 


21K 


2.3K 


Median 


101 


430 


235 


19K 


2.0K 


Minimum 


33 


160 


203 


13K 


0.7K 



Table 6-16: Instrumentation data 



Instead, the illustration editor used to create the diagrams used in this thesis was instrumented to measure 
both response time and memory usage. The detailed measurements are given in Table D-4 in Appendix D, 
with a summary given here in Table 6-16. This table gives the maximum, minimum, median, and mean for 
each value. These tables list the number of items in each figure, the time for display in milliseconds, the 
resulting rate (including both creation and display) in items per second, tiie memory that would be needed to 
store Uie bitmap (in thousands of bytes), and and the memory used in the SDF (also in diousands of bytes). 
The average times were under half a second, resulting in quite good response. The memory savings averaged 
around a factor of ten for using an SDV instead of a bitnriap, 

6.7.1 Levels of Responses 

Unlike other studies which consider throughput the factor to be optimized, we have concentrated on 
optimizing response time. Experiments have shown diat users prefer systems with low variability of response 
time, even if the throughput is slightly lower [98]. 

One natural division of functions from a linguistic point of view is into tiic following three general 
categories [151]: 

Lexical These operations require immediate user feedback, on the order of 50 milliseconds. This rate 
(20 events/second) corresponds roughly to an upper bound on tlic speed of very last typists 
(keystrokes/second). 

Syntactic These operations involve a single syntactic operation, afid can take up to 0,5 to 1 second. 

Semantic Major operations can take on the order of tens of seconds without Uie users losing their trains 
of Uiought 

Clearly all lexical interactions should be performed on the workstation. In fact, tiie VGTS line editing and 
cursor tracking account for most of tiiese lexical actions. Syntactic actions include screen management and 
selection feedback. In Uie VG TS these operations are typically performed outside tiie service, but in 
programs residing on tiie workstation. Syntactic responses can even be done across tiie network if tiie load on 
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the remote host is not very high. Larger-scale semantic operations, like loading and running large programs, 
searching central databases, or compilation, are typically done on remote server hosts or distributed between a 
server host and the workstation. 

6.7.2 Keystroke Data 

Many studies have been done for text editors to determine the common operations [26, 57]. These studies 
can be extended to graphics, but are also valuable in their own right since a large part of any user's interaction 
is still textual. The main conclusion of these studies is that the majority of the users' time is spent doing very 
simple repetitive tasks. Thus we concentrated on making these few simple tasks faster by taking advantage of 
the power of the local workstation. 

6.8 Discussion of Results 

To summarize our findings, the primary factors affecting performance of our distributed graphics 
applications are, in approximate order of importance: 

1. Speed of the workstation. 

2. Speed of the remote host, if any. 

3. Level of communication, as determined by the virtual graphics terminal protocol. 

4. Bandwidth of the networks employed. 

Essentially the same observations hold for text. Note that these observations relate to the degree of 
performance improvement relative to the degree of change in the indicated parameters. Thus, a 50% 
performance improvement due to a 200% increase in processor speed could be considered relatively greater 
than a 300% improvement in performance due to a 6000% increase in network speed. The importance of 
CPU speed and amortizing communication costs over large buffers was a major conclusion of one of tlic few 
other similar studies [85]. 

It is relatively easy to rate the sensitivity to hardware factors. Software factors are another matter; it is easy 
to measure die absolute performance improvement resulting from a change in software, but quite difficult to 
measure die cost of the software change. Neverdieless, certain conclusions will be drawn based on available 
information. Also note diat Uiere are limits beyond which changing one factor will not alTect perfonnance; 
for example, a CPU-bound application running on a remote host will be little affected by an increase in 
worksttition speed. 

CPU speed rates at the top of the list simply because desired speed-ups can be achieved almost indefinitely 
by substituting more powerful workstations and baci(end hosts. Continuous improvement is not possible with 
network protocols. IKP, for example, provides as good performance on the local net as can be achieved. 
Another way of saying this is that network protocols are limited by die available hardware, and die most 
important piece of hardware is die CPU. 

6.8.1 Hardware Factors 

As workstations become more powerful, one might think that offloading fimctions from hosts to the 
worksUition means that slower backend hosts can be used. In reality, faster hosts are required to keep up with 
the increased demands of tiie workstations. On die oUicr hand, one might think diat as networks become 
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faster, communication is clieap. Unfortunately, network interfaces have not kept pace with bandwidth, so 
that many network operations remain CPU-bound. In both cases, the offloading and increased bandwidth 
may allow more users to share the same resource, but do not increase the performance for individual users. 
Hence, 7&5/er hosts are needed, not slower ones. 

Similarly, network controllers are now being marketed with microprocessors that are intended to offload 

taskb from the main processor. Our experience has been tliat such controllers are usually slower, not faster, 
than simpler and cheaper controllers that perform fewer fimctions but use fixed logic at a higher speed. 

With respect to network bandwidth, sensitivity is directly related to communication requirements. 
Communications requirements are inversely related to the frequency of communication and the amount of 
information transmitted, both of which are reduced by the techniques discussed above. Therefore, the 
remarlcablc inscnsitivity of our applications to network bandwidtli implies that they are quite sensitive to the 
"level" of communication. 



6.8.2 Software Factors 

This high level of communication is due to the Virtual Graphics Terminal Protocol design. In particular, 
the ability to batch many operations into a single update using a small number of bytes provided large 
increases in performance. 

It is hard to make direct comparisons about network protocols independent of their implementations. For 
example, a protocol inside the kernel of an operating system is usually more responsive than if it is 
implemented on top of the kernel. Of course, a processor runs at the same speed both in kernel and user 
state. The increased responsiveness comes with the cost of increasing the size of the (usually always resident) 
kernel and the related difiiculties of debugging at lower levels. 

In our particular case, despite the fact tliat the PUP protocols are simpler than tlie Arpa Internet protocols, 
Arpa Internet-based Thlnizt connections can sometimes run about twice as fast as PUP-based ones. This is 
attributed primarily to tlie fact that PUP is implemented as an application outside die Unix kernel whereas 
tlie Arpa Internet protocols are implemented inside the kernel. 

For very time-critical functions such as network communications, messages and process context switches are 
expensive even in systems designed to provide very fast message passing and light-weight processes. ITie 
interested reader should refer to [82] for a more detailed analysis of the networking issues which arc not of 
direct concern of this thesis. 

6.8.3 Fitting the Model 

'ITie experiments given in this chapter give some estimates of tlie times used in tlie models of Section 5.3. 
For example, pe;ii( pipelined incremental rates are about 60 interactions per second, or TfvjgjQyj + ^ jsjetin 
about l/()Oth second. If this is less tlian the swapping 'rj.^,|p,|^ + I ;5v*f',pOiii worksUJtion/host 
split will be faster, even with comparable computation times. Most of today's personal computers r*ike much 
longer than 1/60 second to swap an application out and back in. The advantage will increase with more 
powerful hosts and less powerful workstations. 

Of course, care must be taken when generalizing these results to other programs. These benchmarks were 
intended as communication-intensive limits, since they only do graphics and no real computation. More 
sophisticated applications could be expected to achieve even larger speed-ups when distributed. ITie 
instrumcntiition results show that the synthetic benchmarks are not fundamentally different from actual 
applications, except for slightly slower rates due to the computation by tlie application. No claim is made that 
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these results allow us to predict the performance of an arbitrary program. On the other hand, a protocol that 
provided one hundred items per second in our experiments will probably be faster that one that provided ten 
items per second. More analytical work needs to be done to accurately predict performance, but tliese results 
provide a start. 
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Conclusions and Future Work 

The previous chapters described the motivation for, the design, implementation, rationale, and 
measurements of a simple distributed graphics system. This Chapter draws a number of conclusions from this 
work, and presents possible extensions for the future. 

7.1 Structured Display Files and Virtual Terminals 

The first important conclusion is that the structured display file technique can be combined with the virtual 
terminal concept, resulting in an architecture for distributed graphics. ITie virtual terminal concept, described 
in Section 2.3, provides the user with access to multiple simultaneous distributed resources. The Virtual 
Graphics Terminal Server mediates between application programs that share a workstation dedicated to a 
single user. 

The declarative nature of structured display files outlined in Chapter 3 reduces communication, and allows 
higher-level short circuiting. The performance and decre^ed memory utilization motivations for structure 
given in Section 5.1.1, are supported by the measurements in Section 6.5.1. In particular, SDFs can yield both 
higher performance and lower memory requirements tlian traditional graphics systems. These advantages 
increase as pictures become more structured, and applications perform more incremental updates. The 
VGTS performs cursor motion, screen management, and keyboard echoing internally (as described in Section 
5.1), resulting in a short-circuit of the interactive response cycle for these common operations. 

7.2 User and Program Interface Separation 

The VGTS architecture first specified only the application program interface for defining and modifying 
objects, in Section 3.4. A separate user interface for viewing those objects was then specified in Section 4.4. 
The prototype implementation rigidly enforced this distinction: applications could not inquire the size of the 
screen, for example, and adapt themselves accordingly. 

The resulting principle advantage is absolute device independence and portability, which is vital for the 
reuse of software with rapidly-changing workstation hardware. Concern for the portability of the prototype 
saved rcimplemcnting most of the modules described in Section 4.1.1 for new devices, such as the Sun-2 
frame buffer. The principle disadvantage is that customization is made more difficult. Section 5.6 discussed 
when customization by both users and programmers is desirable, but also mentioned reasons not to allow 
arbitrary customization. 

7.3 Transparent Distribution 

Although distributed graphics is possible with die SDF approach, it still may not always be desirable. For 
example, in many cases running the benchmarks locally was faster tlian running them distributed. 
Unfortunately, for die reasons given in 1.2.2, it is not always possible to run all applications on the 
workstation. Even if the necessary resources are available as an option for the workstations, they are typically 
too expensive for widespread use. In other words, even with today's advanced hardware, we still need larger 
virtual and physical memories, and faster processors, at lower prices. 

The protocol used for defining objects (the VGTP) was extended transparently across networks using 
several transport protocols, described in Section 4.3.5. The same source program can be compiled and linked 
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for any of a number of environments, and the same binary can be accessed tliroiigh three different transport 
protocols. Distribution allows applications to run on die best suited computational resource, and use multiple 
resources to achieve concurrency. These programs were actually used, so performance constraints were 
stringent. Results such as those in Table 6-6 show that distributed operation was often faster than local 
operation. 

7.4 Techniques to Improve Performance 

The tables in Chapter 6 show that VGTS performance is close to the best possible speed. In the best case, 
the VGTS can give much better response than systems that do not retain any information on the structure of 
the image, or allow for concurrent operation. More instrumentation of applications would provide useful 
information, but is beyond tlic scope of this thesis. The measurements presented in Chapter 6 already 
indicate several ways that performance can be improved. 

7.4.1 Protocol Design Techniques 

Once the decision to distribute is made, a more subjective decision is what and when to distribute. In our 
experience, a few simple operations and applications can be done locally, such as text and illustration editors, 
and the resulting average performance is adequate. The simple but powerful modeling facilities provided by 
the VGTS allow diis short circuiting. 

The use of Structured Display Files also means that once objects are defined, instances of them can appear 
or disappear with a very small amount of communication. This makes the protocols very insensitive to 
network bandwidth, as shown in Tables 6-14 and 6-15. Since delay causes more restrictions than bandwidth, 
many simple operations should be batched together for each interaction. Return values should also be 
eliminated whenever possible to increase concurrency by allowing pipelining to occur. Although direct 
quantitative comparisons could not be made between the factors affecting performance, batching certainly has 
a very important effect 

7.4.2 SoftwareStructurlng Techniques 

One interesting rule of design learned from tlic VGTS implementation experience was to use software 
structuring mechanisms only for the appropriate purpose: 

• Use separate processes where separate Uircads of control are needed, otherwise use one process. 
For example, die main part of Uie VGTS consists of many modules but only one process. 

• Use teams (complete address spaces) for programs tliat should be executed as a unit Partitioning 
the VG'I'S into separate teams caused a great increase in memory consumption, due to the 
common library functions. 

• Use modules for parts of a program that can be separately compiled. A direct procedure call 
interface was still faster than other kinds of communication. 

Much performance can be lost if one of these partitioning mechanisms is used improperly. Even on a system 
like V where message passing is fast it is still slow compared to a procedure call. In particular, Tabic 6-9 
shows that the drawing rate can approach one item per millisecond, which is about the same time it takes to 
perform a message Scnd/Rcceive/Keply cycle. Thus each message should cause many lower-level actions 
instead of just one, reiterating die importance of batching. 
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7.4.3 Internal Performance Tuning Techniques 

Once hardware and protocol decisions are made, performance can be improved by using standard software 
tuning techniques such as inner loop optimization and increasing buffer sizes and blocking factors. In fact, 
reasonable performance can be obtained using die standard transport protocols compared in Table 6-1, 
without resorting to special-purpose protocols and incurring all the problems of being non-standard. On the 
other hand, Uic use of structure and proper batching and buffering strategies must be done at every level, to 
avoid bottlenecks. 

7.5 Wliat Can be Learned 

In light of tlie VGTS experience, we can evaluate some aspects that were later determined to be 
unsuccessiiil, for the benefit of future designers: 

• Tlie declarative nature of the VGTP and lack of a simplified interface library discouraged 
application programmers accustomed to more procedural graphics systems. 

• Application programs developed their own conventions since there were few common user- 
interface libiaries. 

• Encoding graphical information in the same stream as text at the lowest level did not allow 
redirection of graphics commands into a file or background graphics programs. 

• The lack of raster operations in the programmer's interface discouraged the use of the VGTS for 
image processing applications. 

• Several minor device-dependencies in tlie miplementation were not made apparent until ports 
were actually attempted, due to lack of a well-specified device interface. 

© The close coupling of the view manager to die rest of the VGTS discouraged attempts at 
customization through user profiles. 

Most of these problems can be easily overcome by the work described in tiie next section. 



7.6 More Open Questions 

The VGTS effort raised more questions dian it answered. The following is certainly not an exhaustive list, 
but it should give an overview of possible future topics in this area. 



7.6.1 Integration witli Editor 

One useful function in many window systems is the ability to select text (or other data) from one place and 
.y//vy/it into another. Due to the simple structure of text, this would be relatively easy to add for clients using 
the byte-stream terminal emulation interface. For advanced graphical objects, SDF and higher-level 
interfaces could be used. Unfortunately this requires common data representations at the applications level, 
beyond tliat with which tlie current VGTS prototype is concerned. Since some performance and fiexibility is 
already lost by enforcing the level used by the VGTS, getting applications to agree on even higher levels could 
be quite difficult. On Uic other hand, there are many potential benefits from even higher levels of 
standardization. 
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7.6.2 Handling of Attributes 

The VGTS used a limited number of attributes for its primitives, most stored as a small integer used as a 
table index to get the actual value. This approach, similar to bundled attributes of GKS, has proven to be 
simple yet powerful. However, in the VGTS most values are predefined at compile-time; they should be 
dynamically defined at run-time. For example, for text fonts the DefineFont function returns an attribute to 
be used in subsequent Text items. Similar functions should be available to define colors, fill patterns, and 
line styles. 

In keeping with the declarative approach of the VGTS, each item has its attributes explicitly specified. For 
example, if a symbol contains 500 blue lines, then each line contains the information that its color is blue. 
This is in contrast to die approach taken by traditional graphics packages, which would have a command to 
set the current line color to blue and then draw 500 lines. Although the traditional approach requires 
additional state during interpretation of the SDF, it would allow the inheritance of attributes from containing 
environments. An open issue is tlie value of tliis inheritance capability. 

7.6.3 Other Interfaces 

If VGTS allowed inheritance of attributes, then it could support an interface compatible with GKS. The 
application could still take advantage of the structuring capabilities of the VGTS if die interface is upward- 
compatible witli GKS, in the manner of Steinhart [130]. Such a redesign is in progress at the time of this 
writing. 

Other virtual terminal emulators could provide, for example, Napij>s virtual terminals as another possible 
interface. These interfaces could be implemented as an alternadve library package, retaining the current 
message interface. A new message interface could be designed, with the conversion to byte-streams done in 
the I'OLNET programs. The relation between the V-System concept of file instances and VGl'S objects such 
as SDF, VGT, and VGT group could be made cleaner. 

7.6.4 Porting the Implementation 

At die time of this writing, although two totally incompatible frame buffers are supported, the VGTS has 
not yet been fully ported to another graphics device besides SUN workstations. Many potential graphics 
devices were either too expensive or provide too low a performance level to adequately support an 
implementation of the VG TS. A port is currently in progress to ilie VAxStation, which should prove Uiat the 
implcmentiition is independent of processor architecture as well as graphics architecture. 

7.6.5 Multiple View Surfaces 

Another aspect of die design never fully exploited was the use of multiple screens per workstation. A 
typical configuration might have a color screen for computer aided design, and a black and white screen for 
general textual interaction. Applications should run with no modifications on such a configuration. A natural 
extension of tlie user interface (used on other systems with multiple view surfaces) would have one cursor for 
both screens. When die cursor is moved past an edge on one screen, it appeal's on die edge of die adjacent 
screen. 

Most of the current VGTS implementation could be used with multiple view surfaces. The internal data 
structures for views could easily be augmented by a pointer to a frame buffer descriptor structure, containing 
pointers to the primiUve functions to operate on the particular frame buffer. This approach is similar to die 
pixrect specification by SUN Microsystems [123]. In fact, pixrect would be a good candidate for this layer, 
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were it not proprietary to a single manufacturer. Another candidate would be one of the Virtual Device 
Interface standards, or normalized device coordinates at a well-specified internal interface. 

7.6.6 Extended Functionality 

Since the VGTS evolved in an environment rich in system programmers, there was no shortage of suggested 
enhancements, including three dimensional SDFs, color, floating-point, image processing, and general 
coordinate transfoimations. Currently the few programs that use floating point or three dimensions execute 
on server hosts in batch mode, because our workstations do not have adequate numeric performance. The 
batch programs convert to two-dimensional integer coordinates tliat arc then displayed by the VGTS. Simple 
animation is possible in the current implementation, by defining successive stages as symbols and then rapidly 
changing between the symbols. Future floating point processors in workstations may make it possible to 
absorb some of tliese functions into tlie workstation's viewing service. 

A fourth dimension, time, could also be considered for actions like animation or rubber banding. One 
approach would be to add graphics primitives that would cause changes to the screen, but not be stored in an 
SDF. These would be similar to temporary (or non-retained) segments in the Core, but would conflict with 
the declarative nature of the current design. More attractive would be to specify rubber banding or trajectory 
as attributes of objects. 

7.6.7 View Adapting Objects 

One principle advantage of tlie up-call approach taken by most object-oriented window systems is the 
ability for graphical objects to adapt to their viewing environment. For example, when a view becomes 
narrower, document paragraphs could be reformatcd to break into correspondingly narrower lines. Similar 
functionality could be added to the VGTS in several ways. The current VGTS includes a function to return 
tlie size specified by tlie user for a default view. This could be extended to allow querying the view for its size, 
but requires some kind of asynchronous notification which would be hard to cleanly add to tlie architecture. 
The notification could be done on the basis of VGTs instead views, since VGTs are already visible objects to 
clients, and multiple views are allowed per VG T. However, in the prototype a graphics VGT has no size, and 
a text VG T is a fixed size once created. 

A more promising approach is to specify the viewing constraints as additional attributes of the object. For 
example, the current prototype implements "reference lines", displayed as lines with text labels drawn near 
the edge of the views in which they appear. Thus the same object in the same VGT can appear diftcrently in 
different sized views. The key problem is to design a method of specifying these viewing constraints with 
more generality but retaining adequate performance at viewing time. 

7.6.8 ViewManagerSeparation 

One of the most requested areas of customization was the view manager. The VG TS architectural 
distinction between the application program's interface and the user's interface means tliat users should be 
able to experiment with alternate, or parameterized view managers without affecting any application 
programs. For example, tiled and overiappcd viewports should both be provided. In addition, work needs to 
be done to develop more advanced command interfaces on top of tlie VGTS. 
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7.7 Final Evaluation 

Even with the deficiencies noted in Section 7.5, few other systems provide as powerful a set of features on 
equivalent workstations. The VGTS approach is well-suited to environments under the following conditions: 

1. Workstations can provide adequate user response without requiring performance extremely close 
to hardware speeds. 

2. Computing resources much more powerful than workstations are available across some kind of 
network. 

3. Portability and device independence is important due to a heterogeneous or rapidly changing 
hardware base. 

4. Productivity of potential users could be increased by providing multiple simultaneous contexts. 

5. Application programs deal primarily with incremental changes or structured pictures instead of 
producing images to be only viewed once. 

As a result, the VGTS is in daily use at Stanford and several otlier sites. Moreover, it has been valuable for 
the performance measurements and design studies described here. 
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— Appendix A — 
Glossary 



This work encompasses three different subficlds of computer science: Operating Systems, Networks, and 
Computer Graphics. Unfortunately some terms have different meanings in more than one of these fields. 
I'his glossary should help to provide one set of consistent definitions. Many of tliese definitions are adapted 
from the literature [161, 64], while others are particular to this work. For more details, refer to tlic references 
provided in the bibliography or the text section as indicated. 

Adis a system developed by Robert Sproull at Xerox Palo Alto Research Center [127] to allow an 

InterlJsp program running on a timeshared computer to perform raster graphics operations 
on a workstation. 

ANSI American National Standards Institute. In the United States such standards are voluntary 

only. Computer related stiindards can be obtained from the X3 Secretariat at tlie Computer 
and Business Equipment Manufacturers Association in Washington D. C. 

Arpa Advanced Research Project Agency of the United States Department of Defense. An agency 

that funds major computer science research projects, including the Arpanet, a nation-wide 
computer network [106]. 

APA All Points Addressable. IBM terminology for a bitmap raster graphics device. 

Backend The part of a computer system (hardware or software) that docs not interact with a user. It is 
separated from interaction v/ith the user by tlie front end. For hardware, backends can be 
optimized for batch operation, favoring throughput over response time. For software, 
requests are made from other programs or software modules instead of directly by the user. 

BCPL Basic Cambridge Programming Language. A very simple language with control structures 

but no data structuring facilities. 

BitBlt Bit-boundary BLock Transfer. The operation of moving blocks of bits from and to arbitrary 

locations within computer words. 

Bitgraph A terminal built and marketed by Bolt Bcranek and Newman of Cambridge, Massachusetts, 
based on an MC68000 processor and a bitmap display. 

Bitmap A digital image memory containing a description of each of the addressable pixels in a raster 

display. The color or intensity level of each pixel is directly determined by tlie value of a set 
of bits in the bitmap. 

Blit A teriTiinal built at Bell Laboratories based on an MC68000 processor and a bitmap 

display [72]. A rcciiginccrcd version is being marketed under the name Teletype 5620. 'Hie 
screen management software supplied for the lilit is called Layers [105]. 

BSP Byte Stream Protocol. A transport protocol in the PUP Internetwork Architecture [19]. BSP 

implements a reliable virtual circuit on top of the internet datagrams of the network layer. 

C A programming language designed at Bell laboratories for the Unix operating system [71]. 

The language is above tlie level of assembler, but allows machine-dependent constructions 
for low-level systems programs such as device drivers. 



CAD 



Computer Aided Design. The application of computers to the design process. 
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Cages Configurable Applications for Graphics Employing Satellites. A system developed at the 

University of North Carolina that allowed a programmer to assign modules in interactive 
graphics programs to one of two processors at load time [62]. The implementation used an 
IBM 360/75 connected to a DEC PDP-11/45 with 88K bytes of memory. Programs were 
written in a subset of PL/I. 

Calcomp California Computer Corporation. An early manufacturer of computer graphics output (pen 
plotting) devices. 

Cedar An experimental computing environment developed at Xerox Palo Alto Research 

Center [46], using the language Mesa [99] with extensions taken from IntcrLisp [138]. 

Clipping A process to insure that an image lies within a certain (usually rectangular) boundary of 
visible space. 

Core a graphics subroutine package specification developed in 1979 by the ACM SiGGRAPii 

Graphics System Planning Committee [147]. 

CPU Central Processing Unit. ITie part of a computer system tliat fetches and executes 

instnictions. 

Cursor A special symbol used to specify a particular position on a screen. 

Datagram A network protocol in which every packet includes a full address and is routed separately 
from all other packets. This is in contrast to virtual circuit networks in which addressing and 
routing are performed on a connection basis. 

DFS Distributed File System. A general concept (providing network transparent File access), and 

in particular a project at the Xerox Palo Alto Research Center to develop a distributed file 
system [134]. 

Display File A data structure used to generate an image. Foley and van Dam discuss the many possible 
uses for display files [56]. Alternately called display lists or display buffers. 

DISDB Device Independent Structure DataBase. A concept in die Lawrence Berkeley Laboratories 

Network Graphics System [24], similar to the Wiss of GKS. Application programs use the 
workstation-independent layer to create, modify, and delete information in the database, 
while the workstation-dependent layers read the structure information to update die displays. 

Dragging 'ITic translation of a selected displayed object along a path specified by a graphic input device. 
ITiis is a form of image transformation. 

Dorado A high-performance personal scientific computer built at Xerox PARC [75]. 

Dynabook A concept of a powerful portable personal computer system that could be used in education 
much like a notebook is currently being used [90]. 

Hmacs A screen display editor that is extensible by using an interpreter for a powerful 

language [129], The original version was implemented in 1974 for tlic Di-cSystem-lO and 
DECSystem-20 line of computers, lliere are now many versions for a variety of machines 
and operating systems. 

Escape A facility to access functions that are normally not part of the interface specification. 

Ethernet A particular kind of local area network that uses carrier sense multiple access with collision 
detection. The official specification for tlie datii link and physical layers was developed 
jointly by Xerox, Digital Equipment, and Intel Corporations [44]. 
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Extent Also called the bounding box. The smallest orthogonal rectangle containing the object in 

question. This is obtained by calculating the maximum and minimum coordinates of the 
objects along each axis. 

Frame Buffer The digital memory used to store the bitmap in a raster display. 

Frontend .The part of a computer system that deals with tlie user. The frontcnd should be optimized 
for fast response time, with longer operations made part of tlie backend. 

GKS- Graphical Kernel System. A standard graphics package definition adopted by the 

International Standards Organization [64] and the American National Standards Institute. 

Hit Detection The operation of associating an event on a graphics input device" with an item in tlie display 
list. This is tlie function of a Pick device. 

ICOPS Interconnected Processor System. A graphics system developed at Brown University to 

dynamically distribute parts of an application program between two processors [97, 146, 128], 
an IBM 360/67 and a Mcta 4 with 64K bytes of memory and a 50K bits per second serial 
connection. A single application program written in the Algol-W language was used for 
performance measurements. 

IKP Inter-Kernel Protocol. The protocol used in the V-System between kernels to provide the 

transparency of message passing. 

Inquire Operations that return information from the graphics system; 

InterLisp An experimental computing environment developed at Xerox Palo Alto Research Center, 
based on a form of the Lisp language [138]. The InterLisp system has been ported to several 
different computing environments, from personal computers to timesharing systems. * 

IP Internet Protocol [106]. A network-level protocol used in the ARPANET. 

Iptn Internet Protocol TelNet. The V-System program that allows a user to have a terminal 

session on a remote server host. 

Iris Integrated Raster Imaging System. A high-performance color graphics workstation 

developed at Stiuiford University [39], and now marketed by Silicon Graphics, Inc. of 
Mountain View California. 

ISO International Standards Organization. 

Keystroke One user action, such as pressing a key on a keyboard. Used to model the psychology of 
human-computer interaction [26]. 

Layers A software system developed for the Blit terminal developed by Bell Laboratories [105]. 

LRG hearing Research Group. The group that developed the Smalltalk language; called tlic 

Software Concepts Group since 1981. 

Mainframe A very large and expensive computer, typically purchased by a group and maintained in a 
computer rqom. 

Mbyte Megabyte. The twentieth power of two, number of bytes, usually referring to computer 

memory. Actual number is 1048576, significantly larger tlian one Million. 

MC68000 A currently popular microprocessor produced by Motorola Corporation [100]. It is a 32 bit 

architecture [69], with several different implementations. Unfortunately tliis name was used 
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for both the architecture and the first implementation (a 16 bit implementation with 23 
address bits). 

A language developed at Xerox PARC for writing systems programs. Mesa supports systems 
of separate modules with controlled sharing of information. The basic Mesa language has 
been extended in the Cedar experimental programming environment [46], 

MegaHertZ. One million cycles per second. One parameter of microcomputer performance 
is the clock speed. 

Million Instructions Per Second. A common (but inaccurate) measure of computer system 
performance. 

A graphics input device that operates by sensing relative position changes when traveling 
over a flat surface [50]. 

Multiplexor. A device which mediates between several entities all wishing to use a common 
resource. 

Nortli American Broadcast Teletext Specification [11]. 
North American Presentation Level Protocol Syntax [6]. 

Normalized Device Coordinates. A very low-level but resolution independent coordinate 
system. For example, the coordinates of the view surface as floating point numbers ranging 
from zero to one with (0,0) the lower lell corner and (1,1) the upper right. 

Network Graphics Protocol. The transport layer protocol used to communicate between a 
workstation and the system running a remote graphics application. 

Network Graphics System. Designed at the Lawrence Berkeley Laboratory [25], and partially 
implemented [24]. 

oN-Linc System. A software system developed at SRI [49] that used computers with graphics 
workstation to augment tlie abilities of knowledge workers. It is now marketed by Tymcsharc 
Corporation. 

N-channel Metal Oxide Silicon. A process for making very large scale integrated circuits [93]. 

Network Virtual Terminal. A concept originally developed for long-haul networks [162], to 
ease the connection of a variety of real terminals to a variety of computer systems without 
having to support all possible combinations. 

'llie Xerox Palo Alto Research Center. 

IBM terminology for Pixel. 

A workstation built by Three Rivers Corporation [144]. 

Programmer's Hierarchical Interfiice to the Graphics System. A draft standard for a graphics 
package with hierarchical segment structure [4], 

A graphical input event which returns the identification of an item within a display file. 

An operating system for workstations developed at Xerox Parc, written in the Mesa 
language and used as tlie basis for tlie Xerox Development Bnvironment [160]. 



GLOSSARY 



101 



Pixel Picture Element. The smallest display area on a raster display surface whose characteristics 

can be controlled independently of its neighbors. 

Pixrect A layer in the graphics architecture of SUN Microsystems Inc. [123]. 

Pop-up A type of menu that only appears when a choice must be made. 

Pty Pseudo-terminal An operating system object tliat behaves as a terminal on one side, but 

communicates to a program (typically a server 1'elnet) on the other side. 

Raster A rectangular array of pixels. A raster display is one that use an array of pixels to produce the 

image, in contrast to a series of lines, for example. 

RasterOp A Raster Operation. One of the many bit-oriented operations between one two bit-arrays 
producing another bit-array [103]. 

RPC Remote Procedure Call. An attempt to preserve the semantics of local procedure calls across 

a network, usually done as an extension to a compiler [102]. 

RS-232 A Recommended Standard 232 of the Electronics Industries Association. Used to connect 

most low to medium speed terminals to computers. The communication is full-duplex using 
twisted pairs between two points, over short distances. A functionally similar interface used 
outside the United States is ccrrr specification V24. 

RTP Rendez-vous and Termination Protocol. Part of the PUP Internetwork Architecture [19], 

used to set up and terminate byte stream protocol connections. 



Rubber Banding 



An interactive technique that moves the common vertex of one or more objects such as lines 
while the other end points remain fixed. 

Scan Conversion 

Hie process of converting an image defined in terms of graphical objects into a raster (array 
of pixels). 

Screen Coordinates 

Device dependent coordinates, usually integer raster units. Only the lowest-level device 
driver uses tills coordinate system. 

Scrolling Continuous vertical (or horizontal) movement of display elements witliin a viewport. As new 
objects appear at one edge (such as lines of text along the bottom), old objects disappear at 
die opposite edge. 

SDF Structured Display I'ilc. A directed, acyclic graph of items, each of which is cither a primitive 

Item or a symbol, which is a list of other items. SDKs are manipulated via the VG TP, which 
is described in Section 3.4. 

Segment An ordered collection of output primitives defining an image. 

SIGGRAPH Association for Computing Machinery Special Interest Group on computer Graphics. 

Smalltalk A language and system developed at the Xerox Learning Research Group, now known as the 
Software Concepts Group [58], 

SUN SUmford University Network. Also applies to a particular workstation, a tiademark of SUN 

Microsystems Incorporated. 
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Symbol A list of graphical items grouped togctlier and given a name. This name can be used to add 

instances of the symbol to other symbols, producing levels of structure in an SDF. 

TCP Transmission Conti'ol Protocol. A transport protocol in the Arpa protocol architecture [106]. 

Telnet A protocol to allow remote logins [107]. 

TOPS-20 A timesharing system from Digital Equipment Corporation for the DEcSystcm-20 line of 
computers. 

Unix . A portable timesharing system developed by AT&T Bell l..aboratories in the early 1970s fill]. 

User The human end-user of a computer system or set of software. Thus the user interface deals 

with the person trying to use the system to get work done, in contrast to the programmer 
interface which is used by the developer. 

VAX Virtual Address extension. A line of computers built by Digital Equipment Coiporation 

with a 32 bit architecture [45]. 

VDI Virtual Device Interface. A proposed standard interface between a graphics package and a 

device driver, as showii in Figure 2-2. 

VDM Virtual Device Metafile. A method for storing graphics information on a file. Figure 2-2 

illustrates how VDM fits into the architecture of standard graphics packages. 

VGT Virtual Graphics Terminal. A concept of the VGTS which combines advantages of 

traditional graphics packages and window systems within the framework of a virtual terminal 
management system. Section 3.4.2 defines tlic semantics of a VGT, which is asst)ciated with 
one item in an SDF (usually a symbol). 

VGTP Virtual Graphics Terminal Protocol. The protocol used between the VGTS and a client. 

Described in Section 3.4. 

View A mapping of a virtual terminal onto a physical output device. Default views are provided by 

tlie application programmer, while die user creates and manipulates views witli the View 
Manager, as described in Section 4.4. 

Viewport A rectangular area of a physical output device which presents the contents of a window. The 
VGTS prototype implementation supports potentially overlapping viewports, so the actual 
areas of the screen Uiat arc visible for each viewport are called subviewports. Section 4.2.1 
describes tiiis process in more detail. 

V-Kernel A small real-time portable operating system kernel [31], descended from rhoth[29] and 
Vcrcx [30]. 

VLSI Very Large Scale Integration [93]. VLSI is both the reason why graphics workstations arc 

becoming economical, and one of the major users of tliosc workst*itions. 

VMS Virtual Memory System. The operating system supplied by Digital Equipment Corporation 

for the Vax computer [45]. 

V-Server A program running within some predefined operating system that provides services such as 
file access and remote execution to clients in a V-Systcm [31]. 

V-Systcm A system of distributed servers and a synchronous message-based kernel developed by Uic 
Distributed Systems Group of Stanford Univei'sity [17], 
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VT Virtual Terminal. A concept originally developed for long-haul networks [162], to ease the 

connection of a variety of real tenninals to a variety of computer systems without having to 
support all possible combinations. 

Vtms Virtual Terminal Management System. An agent in the Rochester Intelligent Gateway which 

managed terminal interaction [77]. 

Wdss Workstation Dependent Segment Storage. A concept used in GKS [64]. 

Wiss Workstation Independent Segment Storage. A concept used in GKS [64]. 

Window That part of the virtual (or world) coordinate space that is being displayed in a particular 
view. This is the standard graphics package terminology [147], in contrast to the "window 
system" terminology (sec Chapter 2) which uses tlie teiin to refer to the view itself, 

Woodstock A stateless file server project at Xerox PARC [137]. One of the first experiments at 
partitioning between an application program and its disk. 

World Coordinates 

The coordinate system of the application program's model of an object. The input to the 
viewing pipeline in most graphics systems [147]. 

Workstation A computing resource dedicated to a user. This may range from a small, fixed-ftinction 
terminal to a large self-contained personal computer. 



Zoom 



Changing tlic scaling factor mapping from virtual coordinates to physical coordinates to give 
the appearance of having moved towards or away from the object of interest. 
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— Appendix B — 
A Short VGTS Sample Program 

The following program has actually been run both under Unix and under the V system executive. The 
#i f def Vsys tern directives allow the programmer to conditionally compile code for one environment or 
the other. It also must be compiled with the appropriate compiler and linked with tlie correct library. It first 
creates an SDF and VGT, then displays 100 random objects of various kinds. 



* test.c - a test of the remote VGTS implementation 

* Bill Nowicki September 1982 
*/ 

include <Vgts.h> 
include <\/io.h> 



define Objects 100 /* number of objects */ 

hort sdf, vgt; 

jit() 
{ 

DeleteVGT(vgt.l); 
DeleteSDF(sdf ) ; ' 
ResetTTYO; 
exit(); 

> 

ain() 
{ 

int i ; 
short item; 
long start, end; 

ifndef Vsystem 

printf( "Remote VGTS test programXn"); 
else Vsystem 

printf("VGTS test programVn"); 
endif Vsystem 

ff lush( stdout) ; 

GetTTYO; 

sdf = CreateSDFO; 

Def ineSymbol ( sdf, 1, "test" ); 

Addltem( sdf, 2, 4, 40, 4, 60, NM, SDF_FILLED_RECTANGLE , NULL ); 
EndSymbol( sdf, 1, 0 ); 

vgt = CreateVGT(sdf . GRAPHICS+ZOOMABLE , 1, "random objects" ); 
Def aul tView(vgt, 500, 320, 0, 0, 0, 0, 0, 0); 
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time(&start) ; 

for (i=12; i<Objects; i++ ) 
{ 

short X = Random( -2, 155); 
short y - Random( -10, 169); 
short top = y + Random( 6, 100 ); 
short right = x + Random( 4, 120 ); 
short layer - Random( NM, NG ); 

EditSyinbol (sdf , 1); 
Deleteltem( sdf, 1-10); 
switch (Random(l, 6) ) 

{ 

case 1: 

Addltem( sdf, i, x, right, y, top, layer, 
SDF_FILLED_RECTANGLE, NULL ); 

break; 
case 2: 

Addltem( sdf. i, x. x+1000, y, y+16, 0, SDF_SIMPLE_TEXT , 

"Here is some simple text" ); 
break; 

case 3: 

Addltem( sdf, i, x, right, y, y+1, 0, 
SDF_HORiZONTAL_LINE, NULL ); 

break; 
case 4: 

Addltem( sdf, 1, x, x+1, y, top, 0, 
SDF_VERTICAL_LINE, NULL ); 

break; 
case 5: 

Addltem( sdf, i, x, right, y, top, 0, 
SDF_GENERAL_LINE, NULL ); 

break; 
case 6: 

Addltem( sdf, i, x, right, top, y, 0. 
SDF_GENERAL_LINE, NULL ); 

break; 

> 

EndSymbol( sdf, 1, vgt ); 

} 

time(8fend); 

if (end==start) end « start+1; 

printf("%d objects in %d seconds, or %d ob jects/second\r\n" , 

Objects, end-start, Ob jects/(end-start) ) ; 
printf ("Donel\r\n") ; 
Quito; 
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»ndoin( first, last ) 
{ 

/♦ 

* generates a random number 

* between "first" and "last" inclusive. 
*/ 

int value = rand()/2; 
value 7o= (last - first + 1); 
value +- first; 
return( value) ; 
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— Appendix C — 
History of the Implementation 



The SDF manager was originally written by Charles "Rocky" Rhodes, incorporated into the Yale VLSI 
layout program by Tom Davis [42], and converted to use tiie V kernel by Marvin Theimcr during tiie summer 
of 1982. Most of the conversion into the VGTS by tlie author was done in late summer and fall of 1982, with 
significant events as follows: 



July, 1982 
August 27, 1982 

September 1, 1982 

September 18, 1982 

October 2, 1982 
November 1, 1982 

January 1983 

February 17. 1983 
March 5, 1983 

March, 1983 
April 5, 1983 

April 20, 1983 



The Yal e program was converted to run under the V kernel. 

The SDF manager operations could be called via C function calls from the Yale 
program, but was a separate module. The window manager and related drawing 
routines could be linked together with any client wanting to use them. 

A terminal program was written to combine standard terminal emulation flmctions, a 
PUP User TKLNirr implementation, and the SDF manager flmctions in one program. 
This was based on an earlier implementation of PUP User TELNnr by the author. 

The terminal program was augmented to decode the escape sequences, so that a 
program running on a remote host could manipulate an SDF. A set of "stub" functions 
was written that allowed programs to run either on the SUN directly or on any host 
reachable through a telnet connection. 

Yale was ported to tlie vax, using the stub routines to simulate die local VGTS 
environment. A few remote test programs were written at diis time, including the 
program in Appendix B. 

Overlapping viewports added. Arbitrary lines were also added and debugged. Another 
test program to display wire-frame drawings projected from three dimensions was 
written. 

A simple illustration editor was written by the author to edit diagrams for papers on the 
VGTS, All of the diagrams in this thesis arc produced with this program. 

The text editor Ved operated under the VGTS along with other executives. 

Graphics applications, including previously mentioned test programs, and both the 
distributed and local versions of the Yale program were operated under the VGTS 
and coexisted with each other. The VGTS/Kxecutive combination was installed for 
production use by other members of the Distributed Systems Group. 

The ability to display text in arbitrary fonts was added, in addition to die special 
fixed-width font. 

Continuous mouse monitoring added, so real-time feedback was possible. Witli these 
new additions to the illustrator program, and the Ved editor, usability was greatly 
increased. The view manager also provided feedback when positioning viewports. 

Raster objects were added, and a test program which displays half-tone photographic 
images was written. Another test program successfully displayed a database containing 
a map of the world. 



May. 1983 



Filled polygons and splines were added, and a drawing editor program was developed 
to test them. 
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July, 1983 

September, 1983 

November, 1983 
July, 1984 



Banners added and integrated into the executive. Screen saver added to turn off SUN 
video if nothing has happened in the last ten minutes. View manager menus were 
reorganized. 

Added line editor and integrated into the executive. Removed line editors from most 
application programs. Added directory protocol support. 

Split off exec server instead of linking directly to executives. 

Initial port to the SUN-2 frame buffer. Only simple text and rectangle objects worked 
at this point. View manager shortcuts installed. 



Other people who have contributed to tlie VGTS implementation were as follows: 

P. M. Bothner Primitives for display of rasters and arbitrary fonts, on both SUN-1 and SUN-2 frame 
buffers. 

K. P. Brooks Continuous mouse monitoring, arc and fast filled polygons, design of GKS compatibility 
package. 

D. R. Cheriton Design of I/O protocol, and the V kernel; Co-principal investigator for the Distributed 
Systems Group. 

T. R. Davis Original application, which was integrated with SDF management and display routines, as 
well as original view manager in the Yale program. 

J. C. Dunwoody Automatic pagination of pad output, simple terminal server, mouse text selection for line 
editor. 

R. S. Finlayson Port to the SUN-2 frame buffer, including most of the graphics primitives for the SUN-2. 



L. Gass 



Hit detection functions (FindSelectedObjeci). 



D. R. Kaclbling Filled splines and polygons, and an application program that uses tlicm (Draw). 

K. A. Lantz Virtual Terminal concept, overall architecture of user interface; research supervisor, and 
Co-principal investigator for tlie Distributed Systems Group. 

T. P. Mann V- Kernel support for frame buffer access, many minor bug fixes in related software. 

j. I. Pallas Improved cursor visibility, some minor bug fixes, and short cuts to get to view 

management functions. 

V. R. Pratt Fast vector drawing function implementation. 

C. C. Rhodes Initial SDF management functions, partial port to the Iris. 

M. M. Theimcr Conversion of Yalu to the V-Systcm, and the internet server. 



Undoubtedly tliere are others who have helped in one way or another, but tliese are the niajor contributors. 



DETAILED EXPERIMENTAL RESULTS 



111 



— Appendix D — 
Detailed Experimental Results 

This appendix contains the specific results from benchmarks and instrumentation discussed in Chapter 6. 
There are three kinds of synthetic benchmarks: text, graphics, and stnicture. Measurements were also taken 
from the illustration editor, using the illusti'ations in this thesis as data. Within each kind of benchmark the 
results are grouped first by workstation type, which appears in the first column. The following workstations 
were used for the tests: 

Sun-1 This was the first model of workstation marketed as model 100 by Sun Microsystems, Inc. of 
Mountain View, California. It is connected to experimental (3 Mbit/sccond) Hthcrnet with a 
controller built by Sun Microsystems. It contains a lOMhz MC68000 processor, with 1Mbyte 
of memory accessed with no wait slates. Keyboard and optical mouse are polled by software. 

Sun-1.5 This was the first upgrade to the Sun-1 by Sun Microsystems, called model lOOU. It is 
connected to standard 10 Mbit/sccond Ethernet with a controller made by 3Com 
Corporation, also of Mountain View, California. It contains a lOMhz MC68010 processor, 
with 2Mbyte of memory accessed with wait states, with a resulting effective speed of about 
SMhz. Keyboard and optical mouse are polled by software. 

Sun-2upg This was another upgrade to the same physical workstation made by Sun Microsystems, also 
called model 2/100. It contains a lOMhz MC68010 processor, with 2Mbytc of memory 
accessed with no wait states. It is connected to standard 10 Mbit/second Ethernet with a 
controller made by 3Com Corporation. Keyboard and optical mouse arc polled by software. 
It is actually slightly slower on graphics tlian the Sun-1, probably due to a different bus 
arbitration circuit. 

Sun-2 This was the second workstation product made by Sun Microsystems, called model 2/120. It 
contains a lOMhz MC68010 processor, witli 2Mbyte of memory accessed with no wait states, 
die same processor as the Sun-2upg, but a different graphics architecture. The screen bitmap 
is larger than the previous Suns, but is addressed as linear memory instead of the clever 
scheme of die Sun-l. lliis makes smaller operations much slower, while large operations 
take about the same time. It is connected to standard 10 Mbit/sccond Ethernet with a 
controller made by 3Com Corporation. Keyboard and optical mouse are connected by 
RS232 serial lines. 

Cadlinc An older but similar workstation design, with an 8Mhz MC68000 processor. Only 512K 
bytes of memory are accessed with no wait states, and anotlier 51 2K bytes are available on tlie 
Multibus. Keyboard and mechanical mouse are controlled by a dedicated microprocessor, 
connected to the MC68000 through an RS232 serial connection. 
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The following server hosts were used in the experiments: 

Diablo A Vax-11/780 running 4.1 Unix during experiments, with 4 Mbyte memory, connected to 
3Mbit/second Experimental Ethernet. Operated by tlie SUMEX project in the Stanford 
■ University Medical Center. 

Navajo A Vax-11/780 amning 4.1 Unix during experiments, with 4 Mbyte memory, connected to 
3Mbit/second Experimental Ethernet. Owned by die Stanford Numerical Analysis group 
of the Computer Science Department. 

Whitney A Vax-11/780 running 4.1 Unix, with 8 Mbyte memory, connected to 3Mbit/second 
Experimental Ethernet. Owned by the Robotics group of tlie Stanford Computer Science 
Department. 

Carmcl A Vax-11/750 running 4.1 Unix during experiments, with 2 Mbyte memory, connected to 
3M bit/second Experimental Ethernet. Owned by tlic Stanford Computer Science 
Department for file server development. 

Coyote A Vax-1 1/750 rimning 4.2 Unix, with 2 Mbyte memory, connected to both 3Mbit/sccond 
Experimental Ethernet and lOMbit/sccond Ethernet. Owned by the Robotics group of the 
Stanford Computer Science Department. 

Gregorio A Vax-11/750 running 4.2 Unix, with 5 Mbyte memory, connected to both 3Mbit/second 
Experimental Ethernet and lOM bit/second Ethernet. Owned by tlic Distributed Systems 
Group, and used for Vax operating system support, both the Vax V kernel port and Unix. 

Pescadcro A Vax-11/750 running 4.2 Unix, with 6 Mbyte memory, connected to both 3Mbit/second 
Experimental Ethernet and lOMbit/second lithernet. Owned by tiie Distributed Systems 
Group, and used as the primary file server for V-System development. 

ISl-A A Vax-11/780 running 4.1 Unix, with 4 Mbyte memory, connected to tlie Arpanei, 
located in die Information Science Institute in Marina del Rey, California, about 500 miles 
south of Stanford. Used for InterLisp support. 

ISI-H A Vax-11/750 running 4.2 Unix, with 2 Mbyte memory, connected to the ARPANET, also 
located in the Information Science Institute. Used for Unix development. 

Camclot A Vax-11/780 running 4.2 Unix, with 4 Mbyte memory, connected to 3Mbit/second 
Experimental Ethernet. Located in the Center for Educational Research at Stanford, and 
operated by the Low Overhead Timesharing System (LOTS). 

Parc-C A Vax-11/785 running 4.2 Unix, with 8 Mbyte memory, connected to the ARPANET. 
Located in and owned by the Xerox Palo Alto Research Center. Used as a mail gateway. 
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The next column gives the protocols used in the experiments. I'hesc were discussed at the bcgining of 
Chapter 6, and are illustrated in Figures 6-1 and 6-2. 

Local The application mns on the same workstation that is used for display. Communication is by 
local V kernel messages. 

VAX-fKP The V-Systcm I/O protocol, using a message protocol implemented directly above the data-link 
layer of Ethernet. The application runs on a Vax Unix system and communicates via pipes to a 
Unix program that simulates a V-kernel by sending kernel packets on the Ethernet. 

SUN-tKi> The application mns on another workstation, and sends V messages directly using tlie Inter- 
Kernel Protocol. 

Pup The PUP Byte Stream Protocol on a directly connected Ethernet. 

Pui'GW The PUP Byte Stream Protocol through one or more gateways to another Ethernet. 

IP Internet Protocol on a directly connected Ethernet. 

IPGW Internet Protocol through one or more gateways. 

A-IP Internet Protocol, over an Ethernet to a pdp-11/23 acting as a gateway to the Arpanet. 

nnnn A four digit number, one of 1200, 2400, 4800, or 9600, refers to the baud rate of a Vax terminal 
port that was attached to an RS-232 port on the workstation. A simple V-System program 
allowed normal Unix terminal sessions on this terminal port. 
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D.1 Text Benchmark 

The text benchmark was primarily a program called tt ime, originally written by Peter Eichcnberger. This 
program simply printed characters as quickly as possible until stopped by an intcrnipt or for a given amount 
of time (two minutes was the time used in these experiments). The columns are: workstation type, server 
host, protocol, and character rate. All numbers arc given as characters per second through all layers of 
software including the terminal emulator, except in the local case where the rates are broken down into draw 
and construction times. For tliese experiments, which were done only with the V protocols, an option of tlie 
V e c t i me p rogram was used. 
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D.2 Vector Graphics Benchmark 

The vectime program was used to test simple vector graphics performance. The columns in the results 
below are: workstation type, server host, protocol, test name, and vector rate. All numbers are in vectors per 
second. The program drew a llilly-conncct 36-agon, and was based on a similar program written by Professor 
Vaughan Pratt. The calculations for tlie points of the polygon were done once before timing began. For the 
Batch test the polygon was erased and displayed ten times, with the results computed over all ten trials. The 
bcnchmaric program reported the standard deviation for tlic trials. Runs widi large deviations were repeated 
on the assumption that transient effects such as incoming computer mail or other background activity caused 
these anomalous results. 

For the Incremental test (noted below as "Add") each AddltemcdW was preceded by an EditSyrnbolaxW and 
followed by an EndSymbol call, to measure the number of transactions per second. Since one run of die 
Incremental test typically took several minutes, these were only repeated once. All experiments were 
performed when timesharing load was low. The last column gives the month and year the measurements 
were taken. 
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D.3 Structured Graphics Benchmark 

The structime program was designed to test the effect of structure. The benchmark drew an array of 30 
NMOS inverters, each consisting of 26 rectangles, for a total of 780 rectangles. The resulting image was about 
400 pixels on a side. Each rectangle was filled with one of four stipple patterns, each representing one of the 
NMOS process layers. In the batch test, each of the 780 rectangles was added to the SDF, resulting in a single 
level, unstructured symbol. The incremental test also used a single-level unstructured symbol, with each of 
the 780 rectangles displayed as it was added. 

In the structure test, a "contact cut" symbol was defined which consisted of Uiree rectangles. Then an 
"inverter" symbol was defined with two calls to tlic contact cut symbol and 20 other rectangles. 30 instances 
of the inverter symbol were then added to the top-level symbol, resulting in a three-level display file. Thus a 
total of 23 primitive items and 32 calls were added to the SDF, for a total of 55 items. All numbers are in 
rectangles per second. Note that the structure create rate might be considered unfairly low. The benchmark 
divided the total time for creation by the number of primitives added, in this case 23. To obtain the rate 
including symbols calls, multiply this rate by 55/23 or about 2.4. The last column gives tlie month and year 
the measurements were taken. 
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Table D-3: Detailed structured graphics results 
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D.4 Illustration Data 

These tests were performed on a local lOMhz workstation with the Sun-1 frame buffer. This table lists the 
number of items, time for display in milliseconds, the resulting rate (including both creation and display) in 
items per second, the memory that would be needed to store the bitmap (in thousands of bytes), and and the 
memory used in the SDF (also in thousands of bytes). These experiments were performed in October of 
1984. 



Egure 



Obiects Time Rate Bitmap 



SDF 



1-1 

1- 2 

2- 1 

2- 2 

3- 1 
3-2 
3-3 
3-4 

3- 5 

4- 1 

4- 2 

5- 2 

5- 3 

6- 1 
6-2 



365 1370 266 34K 

105 430 244 21K 

71 -330 215 17K 

80 360 222 19K 

125 510 245 17K 

137 530 258 19K 

115 490 235 19K 

73 360 203 13K 

88 400 220 20K 

132 540 244 27K 

157 680 231 28K 

66 280 236 40K 

99 390 254 16K 

33 160 206 lOK 

101 450 224 13K 



7.3K 
2.1K 
1.4K 
1.6K 
2,5K 
2.7K 
2.3K 
1.5K 
1.8K 
3.6K 
3.1K 
1.3K 
2.0K 
0.7K 
2.0K 



Table D^4: Detailed illustration data 
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